Remediation against relay attacks (ie. NFC) Question first: Is there any remediation for passive MITM?

I've come across examples of NFC relay attacks which use phones to get around the proximity requirement for NFC payments.

It looks something as this:
[card | phone1] ----------------------> [phone2 | terminal] (normal operation would be [card | terminal]).

Many papers list this as a vulnerability, but I haven't seen any decent way to mitigate against this. One mitigation that I see described is to have stricter timings on transactions, but that would easily be defeated with specialized equipment, instead of off the shelf phones. I guess if you push this, you could in theory limit response times so much that it'd make it physically impossible to do relaying (but then good luck making this cheap and reliable).

TL;DR: Is there any possible mitigation, or are proximity requirements in various technologies basically rubbish?

For NFC technology, the main solution that has been offered to date is distance bounding, in which a tightly timed exchange of challenges and responses persuades the verfier that the prover cannot be further away than a certain distance. This solution, however, has some drawbacks:

It still won't say whether the specific endpoint the verifier is talking to is the intended one or not. It will only tell the verifier whether the real prover is nearby.
    It involves hard real time processing to measure the transfer time and deduce the distance.


What is the difference between HSM and Key server? As per PCI-DSS requirements, we have to use either HSM (Hardware Security Module), or Key Server to store the KEK (Key Encryption Key).

If I'm storing encrypted DEK (Data Encryption Key) in an App Server, how can I securely store the KEK which encrypts the DEK?

The two options:

If I decide to use a Key Server, then if someone hacks the App Server, he could easily gain access to the Key Server. So how to protect my Key Server?
If HSM is used for storing the KEK, then if someone hacks my app server, can they hack my HSM too?

Which of the two would be a more secure way, HSM or a Key server?

The point of a key server or HSM is to isolate the application from the storage (and potentially usage) of the key.  Ideally, you would want to offload and rate limit all cryptography operations to the HSM or Key Server so that the application never has access to the decryption key.

This allows you to do intrusion detections such as rate limits and such to prevent bulk decryption of records if the application server is compromised.  The attacker could still queue up records to be passed through the HSM or Keyserver for decryption, however the spike in the rate of requests would start throwing up red flags that a compromise may have occurred.

Either could potentially be more secure since both provide the same type of isolation.  A key server provides a higher degree of physical isolation, but depending on implementation, the complexity may leave a larger attack surface.  HSMs on the other hand are simpler, but also local.  Either way, if properly implemented, only a vulnerability in the interfaces themselves should allow the key to leak.


How to encrypt data asymmetrically to be decrypt my multiple users I'm designing a chat-like application. Every message sent must be encrypted. Multiple users must be able to decrypt it.

In the early stage, a chat will contains only two chatters. This way I can implement it with a simple asymetric encryption. But later more user could join a chat.

For example, if Bob, Alice, and John want to chat together, when Bob send a message, he has to encrypt it using a public key known by all, then Alice and John must be able to decrypt it, each with their OWN private key (can't be the same has privte keys can't leave device for security reason unless you've got a way to secure the private key exchange).

I guess there is no implementation of such an assymetrical encryption but it must be some workaround to get it worked.

EDIT : After some more research I found out broadcast encryption would be the thing to use. But don't understand how it can work. Let's say my three chatters have a public/private key. When Bob send a message, he still have to send it to encrypt it one time for each users with their corresponding key ? Otherwise how can a different private keys decrypt a message encrypted with only one public key ?

EDIT 2 : For what i understand now, I have to choice:

Store a same symetric key for the chat and send it to all chatters after I encrypted it with their personnal public key. Not that good I think... I should not store such an important key, right ?
Store a public key per chatter, and send an encrypted version of each messages to each of them (encryptted with their own personnal public key)

One simple way would be for the chat originator to generate a unique, throw-away symmetric encryption key. Then the "invitation" packet to any other participant contains the encryption key, itself public-key encrypted with the recipient's public key. Or the "announcement" packet might contain all the necessary encrypted versions of the key.

This way, only the intended participants can come to know the decryption key, and since it is also an encryption key, they may use it to send messages as well as receive them.

This is not the same problem as broadcast encryption, since each participant uses the same key and knows it.

To revoke a participant, whoever has the right to do so sends a revoke packet containing a new secret symmetric key, encrypted with the public keys of the non-revoked participants.


Lighteater - BIOS/UEFI vulnerable I am currently a bit confused, I have read today an article about the BIOS-rootkit Lighteater made by John Loucaides and Andrew Furtaki. In their presentation 'How many million BIOSes would you like to infect?' they explain what they have done. They spoke at the CanSecWest this month. This is real serious, as in a concept of proof they were able to get a a private GPG key in plain text from memory, although using Tails that is just running in RAM.

They said: "The high amount of code reuse across UEFI BIOSes means  that  BIOS  infection is automatable and reliable". As far as I know, UEFI is the successor of the old BIOS. So I am a bit confused about these two terms. What I do not understand is, they say that the UEFI is vulnerable, is the old BIOS vulnerable to these kind of attacks, too? I am asking because I still have an older BIOS and not UEFI, am I vulnerable to these attacks too and have to quickly flash a newer version on my board, if one exists? And what are you doing about this?

First, there's a terminology issue when talking about this stuff. Strictly, 'BIOS' and 'UEFI' are different programming interfaces for the firmware present on PC motherboards. However, in a PC context, 'BIOS' is often used to refer to the firmware irrespective of its API -- that is, "UEFI BIOSes" should strictly read "UEFI firmwares".

(Just to be clear: that's not me picking on your choice of words. This ambiguity is rampant throughout discussions on this subject.)

However, realistically, what @andré-daniel said is right: a lot of PC firmwares are vulnerable to these kinds of attacks, because they're not particularly well-hardened. UEFI just makes it easier to attack in an automated fashion because there's a lot more code sharing and reuse between UEFI firmwares from different motherboard manufacturers than there was between BIOS firmwares.

Remember, though, that firmware attacks require code running on the machine, and it needs to be able to get into kernel mode. So preventing malware from running on your computers in the first place is of paramount importance. Safe browsing habits, anti-viruses, and up-to-date software (especially the OS kernel) will all help.

So, in short, yes, you probably are vulnerable to these attacks. Yes, flashing a more recent firmware is likely to help. But you're dependent on the motherboard manufacturer to release updates, which manufacturers are terrible at doing. So there's actually scarily little anyone else can do, apart from try to prevent malware from running.


How much extra security do the Host part of a mysql user account provide? MySQL users have a username and a Host associated with them, so usually you'd identify the user by 'user'@'host'. The host part is there to assure only clients which connect from that specific host are allowed, even if they happen to have the correct username and password. It also allows two users with the same username, but from different hosts, to exist on the same MySQL server.

But wouldn't it be possible to spoof the host name of the client, so that I claim to be coming from the host of my victim? Do the 'host' part of a user really provide any extra security?

The client does not "present" anything related to host.

The server sees an incoming connection from a given IP and  this is resolved by your mysql server and then compared to host,  so it is not obvious to spoof. Your DNS resolution would need to have been modified first (or upstream DNS servers would need to have been hacked).

So yes,  there is extra security provided by host.


How do I protect my Windows computer against the IPV6 flood attack shown in this video In the DefCon video "Three Generations of DoS Attacks (with Audience Participation, as Victims)", the speaker demonstrates how it is possible to crash a variety of devices by flooding them with IPV6 'Join Network' commands.

2 questions:

Can somebody explain what is going on here to me in more detail
How do I prevent this from happening to my own computer

1- The speaker does a pretty good job of explaining what is happening. To sum up, a Linux machine on the same local network as a windows machine sends out thousands of "router advertisements" (RA). These advertisements are usually sent out by routing devices to tell other devices on the network what network prefix to use, and where to route external IPv6 requests. Every time a machine receives an RA, it refreshes its entries for that network prefix (they time out otherwise), or adds new addresses if the network prefix is different. The demo is showing a windows box adding a new IPv6 address for every RA it receives, causing it to spike the CPU load to 100%.

The speaker says he contacted Microsoft about the issue, and they said they had no plans to fix it. I think that the behaviour shown here is technically up to RFC 1256 [1] spec, which is why there is no plan for a fix. Granted, the OS could allow for the configuration of a maximum number of addresses to configure (Linux and BSD do allow this configuration).

Also, note that the windows machine CPU is pegged at 100%, but still somewhat responsive. The OS has not crashed, and I expect that if left for a few minutes (once the IPv6 addresses time out), it would return to normal CPU utilization. I wouldn't go as far as calling it a "kill every machine that receives the packets" attack (as the speaker in the video claims).

2- How to prevent this from happening to you? The most obvious answer is to turn off IPv6 in the network adapter settings. If you need IPv6, then the solution is to monitor who is on your local network. This attack won't work over the Internet (RA packets can't be routed across the Internet), so your adversary must be local. If you're on a network you don't control (e.g., Starbuck), I really doubt someone would be doing this attack. There are so many other attacks you can do when you're local that making someone's computer hit 100% CPU utilization is just silly.

[1] http://www.networksorcery.com/enp/rfc/rfc1256.txt


WPA2 enterprise credentials involved in encryption? Since encryption keys are session-based in WPA2 enterprise, if person A obtains person B's credentials, will person B's encryption key still be safe? Is there any way person A could use person B's credentials to find the encryption key for a given session?

Basically, it is 802.1x.  Key derivation is complicated.  There is a high-level explanation here: http://www.tldp.org/HOWTO/8021X-HOWTO/intro.html

To answer your question simply, the key (actually there are several keys) is agreed upon by the AP and client based on another key issued by the authenticating RADIUS server.  All of these keys are (ephemeral) session keys, with the exception of the group transient key, which is shared between clients (for multicast and broadcast) but periodically changed.

Simply knowing credentials will not cause you to arrive at the same set of keys as another user of the same credentials, or even the same set of keys you had the last time you authenticated.  Any credentials at all will get you the group transient key, but unicast traffic remains secure.

As with all such things, there is an attack.  To render that traffic insecure, an attacker could set up a rogue AP which acts as a gateway, allowing the target to authenticate to it and in turn authenticating with its credentials to the network.  This is an active MitM, though, not a passive disclosure like you were worried about.


What does a signed Linux kernel image get me? On Ubuntu and possibly Debian systems, you can install packages which contain images which are signed by Ubuntu's EFI key. For example, linux-signed-image-generic-lts-trusty is one of these packages.

Say I have a fully-encrypted disk and an unencrypted boot partition, as is required. I use a PGP encrypted key file to decrypt my disk. What exactly does using these signed images get me in additional security? How trivial is it to generate a "signed" EFI kernel image which is compromised?

With your unencrypted boot partition, malware could theoretically replace your unsigned kernel with its own (say, a hypervisor running your original kernel).  This malware would then be undetectable by your system, while having full access to it.

A signed kernel closes this hole, at least in theory: since the malware hypervisor isn't be signed, a EFI BIOS that requires a signed OS would refuse to load it.

The problem with this is that while a random malware author isn't likely to have a signing key recognized by your BIOS, a state-level actor is, and there's a decent chance that an author working for organized crime will.


How to break MAC address filtering? If a MAC filter prevents you from connecting to a network, how can you break it or include your device's MAC in that filter?

The easiest way would be to just spoof your MAC adress. Just listen to the network, watch which MAC adresses are able to connect and then give your own device the same MAC adress.


When should police be notified about host intrusion? If an attacker gains unauthorized access to a host, or makes unauthorized modifications to information on that host, is it appropriate to contact the police or some other law-enforcement agency?  In many cases, the host in question is in the United States, and the attack appears to originate outside the United States.

I can only provide one Dutch case: A webdesign and hosting company (with approximately 100 clients) had a password hacked that was used for everything. (Yeah, don't get me started on all other security issues there.) A few websites were defaced, and private information from the owner was made public. Overall relatively little damage, but damage with a clear origin (we had the attacker's IP which was not a proxy and traced back to the same city).

We printed out the logfiles that we were able to get together (logging was malfunctioning on most websites...), and my boss went to the police with the information. At the police station, nobody knew anything about computers, but everything was written down best they could. The people usually taking these cases were having a training and would probably pick it up next week.

Next week came and passed. Next month came and passed. We called for updates, nothing. The case would have been a simple lookup (ISPs are required to log which IP is owned by whom at any given time), but they didn't do anything.

To the best of my knowledge, it's now 6 months later and the case hasn't even been looked at yet. I still think you should always go to the police with a breach, but the odds of it being solved are low when there is no big money involved.


When I register on a website, is there a way to know whether or not the site admin will be able to see my password? It seems to me that whenever I register on a website, there is absolutely no guarantee that the administrator will not be able to decrypt and view my password (if they even bother encrypting my password in the first place).

Is there any way to know how securely my password is being stored on a standard website login?

Obviously the best way to protect against this is to use a different password for each site, however that's not the question I'm asking.

If the admin really wants to see your password, then he will be able to do so. He just has to grab it when you send it to the server.

If you want to know what password-dependent data is stored on the server side, then that's another question. In general, you cannot know how they do things, but sometimes you get clues. Basically, the reasonable thing to store is a "password verification token" which is a hashed version of the password, using a proper password hashing function. If they do that, then they cannot retrieve the password and send it back to you. Thus, if there is a "password modification screen" that can show you your password, or if they send back your password to you by email when you click on the "I forgot my password" button, then you know that what they store is unreasonable. Plain Text Offenders is a rage/shame Web site that gathers reports of such occurrences, mostly for being able to point and mock these poorly developed sites.

What you cannot really know from the outside is whether, when they store only hashed passwords, they use a proper password hashing function, or something else. You usually learn how poorly they did things when they get breached in and a list of hashed passwords is extracted: if the passwords get broken at a rate of dozens per second, then the hashing function was quite bad...

Password reuse is too dangerous. You should use a new, specific password for each site -- that way, any ineptitude on their side will be contained to that specific site. To remember all these passwords without having an enormously efficient brain, you may want to use a password manager software, e.g. KeePass.


ATA Secure Erase is too fast I have two SSDs in my laptop. one is SATA 500GB and the other is M.2 SATA 250 GB. I used the following steps for both to securly erase them so that I can sell the laptop:

unfreeze the drives:
 sudo systemctl suspend
Set a User Password: hdparm --user-master u --security-set-pass mypass /dev/sdx
Issue the ATA Secure Erase command: time hdparm --user-master u --security-erase mypass /dev/sdx

I have 3 questions

It is completed too fast in less than 3 seconds. Is it normal?
Does the length of mypass matters?
Whats is the advantage of using --security-erase-enhanced instead of --security-erase

This is most likely entirely normal, because of how modern SSDs are designed.
When you use ATA secure erase it is not wiping the whole disk. It is removing the encryption keys on the drive controller, which are used to transparently encrypt data before it is written to the memory chips. Removing this key is virtually instantaneous as you have discovered.
The alternative would be to erase each memory segment individually. This would be slow and, on an SSD, would shorten lifespan as the memory technology has a fixed amount of erase cycles.
The same technique is used for “factory reset” or “secure erase” features found on modern smart phones and tablets.


TLS v1.0 best cipher for OpenVPN setup I'm trying to setup OpenVPN with as much security as I can. I'm in the process of selecting a cipher for OpenVPN. Which is the safest one, tls-cipher DHE-RSA-AES256-SHA or tls-cipher AES256-SHA?

I've already configured it with these settings:

HMAC: SHA512 for auth option
DH: 2048 bit
cipher: AES-256-CFB

And password is requested during connection.

My OpenVPN version is 2.2.1. Is my setup OK? I took a look at this post as reference, but I'm not sure, if I'm missing something?

For the ciphers, use DHE-RSA-AES256-SHA.

If you use openssl ciphers -v you can get more information about each cipher:

$ openssl ciphers -v DHE-RSA-AES256-SHA
DHE-RSA-AES256-SHA      SSLv3 Kx=DH       Au=RSA  Enc=AES(256)  Mac=SHA1
$ openssl ciphers -v AES256-SHA
AES256-SHA              SSLv3 Kx=RSA      Au=RSA  Enc=AES(256)  Mac=SHA1

From this you can see that both ciphers can be used in SSLv3, both use RSA for authentication (Au=RSA), both use 256-bit AES for encryption (Enc=AES(256)), and both use SHA-1 for the message authentication code (Mac=SHA1).

So the only difference between these two ciphers is the key exchange. AES256-SHA uses RSA for the key exchange (Kx=RSA). DHE-RSA-AES256-SHA uses ephemeral Diffie–Hellman (Kx=DH is Diffie-Hellman for the key exchange, and the DHE is ephemeral Diffie–Hellman).

Diffie-Hellman is slightly harder to break in theory than RSA, but not so much that it will be a deciding factor. DHE offers perfect forward secrecy and because the key is ephemeral (i.e., never stored on disk), stealing the private key is much more difficult. Those two are deciding factors, so DHE-RSA-AES256-SHA should win for security.

The question 1024-bit DHE vs 2048-bit RSA has a better comparison of the virtues of the two key exchanges, and the question Is there any particular reason to use Diffie-Hellman over RSA for key exchange? has a very detailed comparson between the two.


Any way to combine delayed password confirmation with the possibility of users navigating away? We want to set up a flow something like this:

We create account for a high-value user from our admin section
They get an automated email containing login details for our site in some form
They follow the link, confirming their account, and see a form that prominently asks them to reset their password
This seems to be the tricky bit: if they navigate away before setting their password and come back later (having potentially logged out/come from another machine etc) we want them to still be able to access their account without having to request a password reset

As far as I can see there's no secure way of doing this, since it would require at least a repeat-use login token to go to them via email.

So my questions are:

1) Have I missed some way of doing this securely? (with apologies to theI3I, who answered a similar question I posted without the fourth requirement here)

2) One approach we've discussed is sending them a reusable login token with an expiry date, so that a) at least it's not going to get broken by a rainbow attack, and b) we minimise the window of vulnerability. I know this isn't ideal, but (if there's a meaningful way to answer this question) how big a risk is this? Does it matter much how long the use period is? And is there any way to minimise the risk other than just reducing use period (or also-imperfect-but-better way to achieve the same desired effect)?

If relevant, we're using a Rails/Devise backend.

Thanks in advance.

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

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

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

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

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


Captcha against Mitm attacks works? I was pentesting a website that didn't have any security against MITM attacks and discovered that when I was trying to steal the log in credentials attacking myself that the CAPTCHA couldn't connect to the internet (the website was sslstripped to http) therefore I couldn't send the credentials to the website and steal them with my other PC.

Is this a standard response, can it be bypassed? Is it secure to implement it as a defense to MITM attacks?

Searching Google, I found that it isn't, but for some reason, it was good protection when I was attacking myself in that website, so I don't really know what to think.

It sounds like the site you were testing doesn't use HTTP Strict Transport Security (HSTS), or at least doesn't pre-load it. However, it's entirely plausible that the CAPTCHA service is hosted on a site that does use HSTS (for example, Google does for most of its sensitive sites); if your SSL-stripping proxy blocked all HTTPS traffic, then that would simply break the CAPTCHA service. Simply allowing requests that go over HTTPS despite stripping to succeed would fix that. It's certainly not going to prevent MitM attacks from succeeding;

Alternatively, it's possible that your SSL stripping itself broke the CAPTCHA. SSLStrip by necessity modifies the HTTP responses; it's possible that it makes some modification which just breaks something (either accidentally, or because there's some explicit check for SSL stripping in the CAPTCHA's JS). It's not hard to detect SSL stripping. On the other hand, it's not hard to modify the stripping functionality to fool any particular instance of detection code, either.

Bottom line, CAPTCHAs do not protect against SSL stripping attacks, or any other kind of MitM. There's nothing, transport security wise, different about a CAPTCHA than about any other cross-origin (or, sometimes, same-origin) script-initiated request. They (like anything else) might accidentally or deliberately break in the presence of such attacks, but a competent attacker would be able to un-break them, and verify that they are unbroken, before targeting a victim.


How can I detect spyware on a smartphone I'm pretty sure there is spyware on my friend's phone deployed there by her ex. She asked me to find a proof and detect it. I usually sniff my network card with Wireshark to detect such spyware and check them with GeoIP but in iOS it's not possible. What can I do?

Possible signs there is Spyware present may include:

Higher battery usage
Higher than normal data usage
Strange background noise during phone calls
Unknown apps installed
Apple ID login request

Any suspicion of a device being infected, the best course of action in my opinion is to factory reset the device (nuke it from orbit).

If this is not an option, installing a reputable antivirus application from the Apple store may be an alternative course of action.


How can I defend against Heroku (or any PAAS) ID theft? How can I defend against Heroku (or any PAAS) ID theft?

Is it correct to assume that if someone obtained my Heroku credentials that they would have access to any data in my app, regardless of any encryption that might be in-place, due to the fact that they could access my source code, database & environment vars?

If so, wouldn’t that one username/password be a weak link in my app’s overall security?

Yes, your heroku username/password might be a weak link in the app’s overall security, but so would be your database credentials, your router credentials and any other credentials...

As long as you have a strong password in place I would not be worried about heroku ID being stolen any more than any other ID you use.

what you CAN do to improve your heroku account security is enable two factor authentication: https://blog.heroku.com/archives/2014/9/25/two-factor-authentication-ga


Sending an email to a potential scammer I own a website. Someone recently sent some questionable emails through our site to some other members. I wanted to send him an explanation of what our site is for and a warning not to send such messages again.

While these emails are not 100% malicious, I am a little hesitant to send him any email from our normal email account as I do not want our company email address falling into the wrong hands (getting spammed or other bad things).

Is is safe to send this user the warning through our company email or should I do something else to warn him? If so, how can I send him an email without jeopardizing our email account?

Personally, I'd never reply to SPAM / Phishing campaigns. Especially not from a domain you care about -for a few reasons:

Responding lets the attacker know your email address is live
He/She could respond by increasing the amount of SPAM sent your way.. or worse
SPAMmers have little respect for law and "please stop" messages.

Basically, your email will either fall on deaf ears and nothing will happen, OR, they'll respond in a way you won't like.

Recommendation

I'd just add them to the SPAM filtering and move on. You can also report them to your ISP and let them handle it. This takes the burden/risk off of you acting by yourself.


Why do you need message authentication in addition to encryption? I've been reading up on Authenticated Encryption with Associated Data. The linked RFC states:

  Authenticated encryption is a form of encryption that, in
     addition to providing confidentiality for the plaintext that is
     encrypted, provides a way to check its integrity and authenticity.

My understanding is that simply encrypting the data, even using a symmetric shared key, with something like AES or 3DES should be sufficient to verify the data has not been tampered with in transit. If it had been, the message simply would not decrypt.

So, why is a separate authentication necessary? In what situation would you need to have a separate authentication (even using plain HMAC with encryption)?

Encryption DOES NOT automatically protect the data against modification.

For example, let's say we have a stream cipher that is simply a PRNG (random number generator), where the key is the seed. Encryption works by generating random numbers in sequence (the keystream) and exclusing-or'ing them with the plaintext. If an attacker knows some plaintext and ciphertext bytes at a particular point, he can xor them together to recover the keystream for those bytes. From there, he can simply pick some new plaintext bytes and xor them with the keystream.

Often the attacker need not know the plaintext to achieve something. Let's take an example where an attacker simply needs to corrupt one particular field in a packet's internal data. He does not know what its value is, but he doesn't need to. Simply by replacing those bytes of ciphertext with random numbers, he has changed the plaintext.

This is particularly interesting in block ciphers where padding is used, as it opens us up to padding oracle attacks. These attacks involve tweaking ciphertext in a way that alters the padding string, and observing the result. Other attacks such as BEAST and the Lucky Thirteen Attack involve modification of ciphertext in a similar way. These tend to rely on the fact that some implementations blindly decrypt data before performing any kind of integrity checks.

Additionally, it may be possible to re-send an encrypted packet, which might cause some behaviour on the client or server. An example of this might be a command to toggle the enabled state of the firewall. This is called a replay attack, and encryption on its own will not protect against it. In fact, integrity checks often don't fix this problem either.

There are, in fact, three primary properties that are desirable in a secure communications scheme:

Confidentiality - The ability to prevent eavesdroppers from discovering the plaintext message, or information about the plaintext message (e.g. hamming weight).
Integrity - The ability to prevent an active attacker from modifying the message without the legitimate users noticing. This is usually provided via a Message Integrity Code (MIC).
Authenticity - The ability to prove that a message was generated by a particular party, and prevent forgery of new messages. This is usually provided via a Message Authentication Code (MAC). Note that authenticity automatically implies integrity.

The fact that the MAC and MIC can be provided by a single appropriately chosen HMAC hash scheme (sometimes called a MAIC) in certain circumstances is completely incidental. The semantic difference between integrity and authenticity is a real one, in that you can have integrity without authenticity, and such a system may still present problems.

The real distinction between integrity and authenticity is a tricky one to define, as Thomas Pornin pointed out to me in chat:

  There's a tricky definition point there. Integrity is that you get the "right data", but according to what notion of "right" ? How comes the data from the attacker is not "right" ? If you answer "because that's from the attacker, not from the right client" then you are doing authentication...

It's a bit of a grey-area, but either way we can all agree that authentication is important.

An alternative to using a separate MAC / MIC is to use an authenticated block cipher mode, such as Gallois/Counter Mode (GCM) or EAX mode.


Decrypt file using Key and Initialization Vector in Linux I am Salesforce developer but new to the Security World as well as Linux. We encrypted a file with Key and initialization Vector in Salesforce(only symmetric encryption is possible in Salesforce). No we are working with partner team  to decrypt the same in their linux system using gpg and OpenSSL. But we were not able to.

Note : The Key and Vector we are using are in Hexadecimal. and the Algorithm we have used to encrypt is AES128.

GPG approach:

GPG seems to need the Passphrase which does not seem to be the key i've used for encrypting.Would it be possible to decrypt the file with just Key and IV in gpg at all?

OpenSSL approach:

We are also trying to explore OpenSSL if GPG does not work in our case. I have received the below command from the Salesforce product support but that does not work either. i got the response as bad decryption.

OpenSSL> enc -aes-128-cbc -d -a -nosalt -in C:\Testfiles\input.txt.enc -out C:\Testfiles\output.txt -K mywhateverkey -iv mywhateveriv

can the Experts of openssl or GPG shed some light?

First of all, GPG has its own message format. Unless this is what is produced you won't be able to use it for decryption.

Openssl should be the better option for you. According to the documentation link you provided, the encryption is done using the AES cipher in CBC mode with PKCS#5 padding (all of those are important, AES128 is not a full encryption scheme you can use).

The command you gave in your question looks OK. I have to guesses what might caus the problem (assuming the encrypted file, key and IV are correct):

BASE64 encoding: You use the -a switch which indicates BASE64 decoding. Are you sure your ciphertext is BASE64 encoded?
Key/IV format: Did you put the KEY and IV there in the correct format?

As a guide, here is a MWE of such an encryption and decryption with openssl:

$ echo "foo" > input.txt

$ openssl enc -aes-128-cbc -e -a -nosalt -K 0102030405060708090a0b0c0d0e0f10 -iv 00112233445566778899aabbccddeeff -in input.txt -out input.txt.enc

$ cat input.txt.enc
oo9TBVgBrcfUHd5wE3gctw==

$ openssl enc -aes-128-cbc -d -a -nosalt -K 0102030405060708090a0b0c0d0e0f10 -iv 00112233445566778899aabbccddeeff -in input.txt.enc
foo


Multiple OpenPGP encryption keys signed by a single certificatation key? Say I have several different email accounts and I want to use a different encryption key for each of them but still have them all certified under one identity. Is this a good idea and how would I do it?

For example:

Jon Doe (identity; key stored on encrypted external drive) certifies

jon@doe.me (personal conversations only; key stored on trusted Linux machine)
jon.doe@developers.org (conversations with random people; key stored on potentially unsafe Windows machine) and
jon.doe@company.com (business conversations; key stored on Windows machine that I have no control over)

The idea is to have a different encryption key on every device (which is also tied to an account), so if one gets compromised the other accounts are not affected, but my conversation partners would still only have to verify one public key and automatically have my other public keys certified (if, for example, someone would like to converse with me on both my personal and business address).

My first attempt was to add multiple UIDs (email addresses) and encryption subkeys to a keypair but I soon realized that UIDs belong to the public key and clients by default would only use the most recent encryption key (also see Debian  article on how to use a subkey for signing).

My current idea would be to generate a sign-only public key (sign + certify), the root identity, and separate keypairs for each email account (sign + encrypt) and then either certify the keypairs (how?) or build a small web of trust (by setting the trust level "ultimate" "trusted" from the email account keypairs to the sign-only public key?). Is this the way to do it, how would you do it and how can your conversation partners import all of my email public keys by only publishing my master identity?

Also I like to point out this GPG tutorial which argues against using such a type of scheme. The argument being, if I understood it correctly, that you should be more careful with your private key in the first place because users never check revocations anyway. Okay, great, so if my private key is compromised once I'm pretty much screwed with the PGP system? And then again, what's the use of creating a new identity/reputation (Jon Doe the 2nd) if users don't get notified about the revocation of my first identity anyway? I might as well send them a revocation certificate and the new public keys, which are still certified by my old root identity.

You already seem to have realized that there is no way to attach user IDs to subkeys.

You cannot impose ultimate trust on others

The problem with your concept is that while you can issue ultimate trust on your own devices, you cannot impose this for other users. If they're able to validate your "master" primary key through the web of trust, the other keys are still to be validated again, with the effect depending on the kind of trust issued on your key and the trust settings of the validating user.

In the end, all you can do is handing over this kind of handling to the others. Sign your other keys with the "master" key (consider certifying them cross-wise) and hope that (if they care to validate keys) they realize this certification and put trust and certifications on the other keys as they require it, too.

Is it worth the effort?

Consider whether using one signing key for multiple devices is not acceptable, anyway and the gained additional benefits don't weigh up with the effort. If somebody gets hold of your encryption subkey, simply revoke it and create a new one; you will still be able to decrypt old messages, and an attacker can only decrypt what he got hold of (so the exposure will usually be the same compared to different encryption subkeys). Consider switching encryption keys more often.

Personally, I only use one encryption subkey on all devices but my mobile phone, which will get its own primary key in the future (which I will not exchange during signing, but only "loosely couple" through cross-certifications.


How to verify file Integrity? I have downloaded a software(zipped), from a website: example-linux.gtk.x86_64.zip

There is another file given for verification, example-linux.gtk.x86_64.zip.asc, whose content are

-----BEGIN PGP SIGNATURE-----

Version: GnuPG v1

iQEcBAABAgAGBQJUPdCNAAoJEELXCMAlIIx7wV4IAI0GwTHy2biP4vp8E+YnYV4u
erog2kGvyU99bJud8CKfgBCKXSn9KdZovo4vCbOoyiVJ/iC8EHqNiK8J9IOMcbGz
hEcHnWE7LWaJPGnFokSh/UhSszDXIRyBUrq2pLg71cME1RYU/2U85ctHxnzFOziD
L3+rPzeFhJ14MpSWTiFh0fUxf299BzUUJBaKFllNmNHkWS4C/SFKmnmG+U8EIB1P
m/Fk6LP/C5X5OFB/XTmsRZRkMbhrMfn6ykfdNL/ltjynUIaoNJYZm5KJeWlvjyxf
XoBRGHslB4H+yv7Mf0qG9PPNWvBUan65t8YtEqyYlrGgTAzo/Umfkvswuv88TE0=
=yhw9

-----END PGP SIGNATURE-----

I'm using linux machine and I want to know How can I check the integrity of .zip file using .zip.asc file ?

In general and as explained in this ServerFault answer, you need to

add the software vendor's public key to your keychain
get the signature (*.asc)
verify the signature via gpg --verify $THE_SIGNATURE_ASC $THE_FILE

Exact details and commands are in the answer linked above and in the link provided by @Steffen-Ullrich in your exact case.


Cisco says Software-Optimized Encryption Algorithm (SEAL) is more secure than AES256, How? i have been preparing for CCNA Security exam and going through Cisco Netacademy official lecture of IPSec, when I came across this slide,

This slide claims that SEAL is more secure than AES256 (or 128/192), but couldn't provide any proof or detail on how it is more secure except that it is stream cipher which I don't think is a reasonable argument to say its more secure.

I went on Wikipedia, but it didn't provide much details.

Can someone please tell me if there are any proof to back Cisco's claim of SEAL being more secure ?

I think they were lazy with the graphic and we're all overthinking this.

The graphic seems to be simply ranking them by key size, in which case the proper order should be:

  DES, 3DES, AES128, SEAL, AES192, AES256

My guess is they wanted to avoid visual clutter so they condensed all the AES's into the lowest one (added bonus: it makes SEAL look better than it is).

Whether that's flat out wrong or merely misleading is a flame war I'll stay away from.


Wipe data from many storage devices This software for wipe devices of storage:

Active@Kill Disk - Hard Drive Eraser.
Eraser.
Shredit for Windows.
Disk Wipe.
Darik's Boot and Nuke (DBAN).

I wonder if this software is able to use for HDD,SSD,USB,SD

if this software doesn't able to all kinds of devices of storage (HDD,SSD,USB,SD), Please tell me about software can wipe for (HDD,SSD,USB,SD).

thanks.

The quick answer is that an HDD, or a modern SSD that supports SED, will be the easiest to remove data from. USB flash drives and SD cards are very difficult to remove data from. Note that product recommendations are off-topic here, so I can't (and don't wish to) look into the detailed capabilities of each piece of software you mentioned. You should find software which is capable of solving the task, armed with the information I am going to describe to you below.
HDD
There are two ways to wipe an HDD. First, you can overwrite the entire drive with random data or a fixed pattern. You should make sure you have disabled the HPA, as otherwise unallocated data may lie untouched in that area. This technique also has the downside that damaged sectors that are marked as bad but not completely unusable will not be wiped. You would need to manually mark all damaged sectors as good (which can cause problems) in order for this to be completely reliable.
The other technique is to use ATA Secure Erase. On most drives, this will cause the firmware of the drive to overwrite all data, including damaged sectors. Newer drives may transparently encrypt all data (SED), and secure deletion will involve nothing more than wiping the encryption key. Sadly there is no way to guarantee that a particular drive has implemented this properly.
SSD
Solid state drives are a bit different. Due to wear leveling, writing to a particular logical sector will not necessarily map to the physical sector of the same number. This makes deleting individual regions of the drive unreliable. However, these drives also have overprovisioning, which means that a good chunk of flash blocks are kept to the side for use if the drive becomes full. This way, even if your drive is showing 99% full, there is still plenty of free but unused blocks available for the wear leveling algorithm to use. Unfortunately, this overprovisioning space is not located at a fixed address, and a block that holds sensitive information one day may become a block in the overprovisioning space the next. As this area of the SSD cannot be read or written to, it is impossible to overwrite an entire SSD just by filling it up. You thus need to use another technique.
SSDs, like HDDs, typically support ATA Secure Erase. When this is supported, the drive firmware will be able to clear all data on the drive. Most modern SSDs, like some modern HDDs, use SED to speed up deletion. When this is supported, secure erasure can take a fraction of a second.
Another technique is to use TRIM, a command that allows the host to inform an SSD that a given sector or range of sectors are no longer needed. Issuing the TRIM command for any number of blocks will put them in the queue for the garbage collector. A properly-designed SSD will shortly thereafter securely erase the blocks that have been marked for destruction. While this feature is normally used to allow the drive to know what information is no longer needed (an SSD has no concept of a "deleted" file), it is completely possible to use TRIM on the entire drive.
USB and SD
A USB flash drive contains one or more flash memory chips, and a microcontroller. Like SSDs, they support wear leveling (albeit a more primitive type called dynamic wear leveling) and usually have some overprovisioning space. Unlike SSDs, they do not often conform to the ATA command set and thus do not support ATA Secure Erase or TRIM. Wiping data from these storage media is much more difficult. If the information on it is highly sensitive, then physical destruction is a must.


How does this unsigned exe launch without the windows 10 SmartScreen warning? So, I have been working on my own project for which I have been looking into certificates and such. While browsing reddit I found a game which I can launch the exe file, expecting to get a Windows 10 warning message, such as occurs for most games on itch.io, and for my own unsigned applications. To my surprise however, the game just straight up launched without any Windows 10 SmartScreen appearing. This is despite the program not appearing to have any digital signature in the file properties.
How is this possible?
I can only think that it was signed, but for some reason it is not showing that the program is signed.
The game was MidBoss (a legitimate game which is on itch.io and steam) which I downloaded the windows main from: https://midboss.net/classic/
I expected to get a warning like this, but no warnings whatsoever were displayed.

The properties of this application have no digital signatures tab.

Unlike this application which has been signed.

Windows Defender Smart Screen blocks or allows applications based on reputation. The reputation can be either for the application itself, or for the certificate used to sign it. Usually developers sign their code so their Authenticode certificate can build reputation and they do not have to repeat the reputation building process every time they issue an update for their application.
However, an executable (whether signed or unsigned) itself can also build reputation, which seems to be the case here. Enough people have used this particular executable safely that Smart Screen is now confident that this executable is not malicious.


How could I tunnel all actions I do in my VPS from my browser (like PHPmyadmin actions)? I am not of the field of information security so sorry if something I wrote below seems pathetic to you.

I am to defend my server's DB and for that I filtered port 3306 with CSF-LFD and now control my DB only internally through port 80, mainly via PHPmyadmin (PMA) for 2 hours each time (I made PMA to be installed and deleted automatically after 2 hours by a script).

These 2 actions (locking the port and using temporary PMAs) are considered quite safe, but there is one last thing I want to do to ensure extra protection:

I've been told I could make every port-80 based data transition between my PC and my VPS, to be encrypted.

I thought of doing this with a tunnel via OpenSSH so at first I tried a command similar to the following, with my user, ip and private key. The execution brought me into my VPS and I could operate it just fine but there was no encryption for actions I did from my web browser:

ssh user@1.1.1.1 -L 22:localhost:22 -L 80:localhost:80 -i ~/.ssh/user_private_key

Because the command seemingly didn't answer my need I turned to the hosting company and a support adviser told me it's obvious because I already use OpenSSH to login to my VPS itself and any extra encryption I do with it is always only session (CLI) based rather than GUI based hence won't effect data transition done from the browser (I must say it sounds illogical to me - If we tunnel a course between one port to another, like 80 to 80, then everything going through it whether from CLI or GUI should be encrypted).

I learned I could use the SOCKS proxy instead. Is SOCKS really the only way possible way for me to achieve this encryption. Can't I really use OpenSSH?

Thanks,

Update for Xiong Chaimov:

Xiong asked me in the comments below:

  What lead you to the conclusion that actions you took were not
  encrypted?

Two things led me to believe that there was no tunneling between the two edges of port 80:

.1. Command error (as is):

bind: Address already in use
channel_setup_fwd_listener: cannot listen to port: 22
bind: Address already in use

.2. Netstat I/O:

netstat -n --protocol inet | grep ':22':

tcp        0     2.2.2.2:22         1.1.1.1:49214     ESTABLISHED

-

netstat -n --protocol inet | grep ':80'

No output...

Since it's SSH port forwarding, it should be encrypted. There's also a solution in which you don't use the underlying webserver or phpmyadmin, to simply forward the mysql port, such as -L 3306:localhost:3306 and connect to the database using a client such as MySQL workbench (or most IDEs have similar integrated anyways).


How to verify that a clientside-generated object is genuine? I know that general best-practice states not to trust anything generated by the client.

With that in mind, I want to write an HTML5 app that utilises the browser to generate various objects client-side before sending them back to the server. These could be images, text, numbers, whatever - but all of them generated by client-side JavaScript, so as not to burden the webserver and keep things responsive.

Let's say we're using an algorithm to generate some text for the purposes of this example.
The user then selects one or more of these text passages and the app sends them back to the server.

The algorithm for generating them necessarily exists client-side, as does the method for posting the data back to the server.

How can I verify that the data being posted to the server has been generated by the client-side algorithm and not simply edited in Firebug or developer tools?
Any checksum/hashing algorithm I might use would also have to be present client-side and therefore vulnerable to tampering as well.

Can this be done without relying on the security-by-obscurity of 'hidden' <input> fields and obfuscated code?

You can't prove it, no. It's on the client machine, so any code or data you hand them is theirs to change. At best you can make it difficult, with obfuscation and DRM techniques, but that's likely to introduce other problems.

The only solution to this problem is to perform operations on the server.


Do I need to use salt with api key hashing? I will generate api keys. I plan to store their hashes instead of plain text. do i also need salt, similar to storing password?

AFAIK salt prevents rainbow table attack and those are more sophisticated way of a dictionary attack so i guess salt is not necessary but i would like to confirm that

No. You do not need to add a salt to an API key's hash.

The API key should have been created from a high entropy random source, capable of resisting attacks that attempt to guess future keys based on past keys.

Most passwords are created from very low entropy sources: Users.  Additionally, most passwords will also be reused, so there's value in pre-computing hashes for the most common passwords.

The largest easily available brute-force rainbow tables are MD5, alphanumeric, up to 9 characters long tables, which assuming that means Arabic numerals and the upper and lower case US-English alphabet, without accents, then we have 58^9 possibilities.  I don't expect to see rainbow tables longer than 10 characters for any hashing algorithm, so as long as your API key is more than 60 bits (58^10 ~= 430 quadrillion, which is less than (2^61)-1 ~= 576 quadrillion), you're probably safe from rainbow tables.

Use 128 bits to be sure, though.  That way you'll be safe from rainbow tables until the heat death of the universe, even if the person attempting to build such a table has a planet sized computer.

You can still add salt if you want to, though, or if you have a manager with an incomplete understanding of security who assumes that salt must always be used with hashes.  Just be sure that the key itself is still long and was created from a high entropy source.


Rating social engineering threats in a penetration test report Does anybody have advice on how to deal with social engineering in the context of writing up a penetration test report?

How do you assign a rating to social engineering? Obviously if you can convince a user with admin access to modify or delete a file, or to shut down a server, then it's a high risk.  Is there a standard like the CVSS (https://nvd.nist.gov/CVSS-v2-Calculator) that should be used to rate it?

I'm not sure that I would rate it at all. Rating requires that you can define the limits and boundaries of the risk. The potential for every social engineering attack is extremely high.

If you successfully performed a social engineering attack, then I would simply list the event and the extent of the effect you had.


White hat hacker asks for account to do penetration tests Our company has online app that requires to create a business account. Yesterday some suspicious accounts were made and our system automatically blocked the account creators and ip addresses.

And today we have received an email saying "Hello my name is [name], I am white hat hacker and want to perform penetration tests on your website. Please enable my account".

What should we expect? What is he trying to achieve?

The person who contacted you was most certainly not a "white-hat hacker". This is not how they operate. The person is most likely trying to scam you in the simplest possible way.

What is a White-Hat Hacker?

In the simplest terms, a White-Hat Hacker (henceforth called "White-Hat") is a security professional hired by a company, group or individual (henceforth called "customer") to test a system owned by said customer.

The White-Hat and the customer agree on a scope of the test, the timeframe, how vulnerabilities should be reported, user accounts for systems to be tested and similar agreements. This is usually referred to as a "Permission to Attack" and is the legal basis of the work of a White-Hat.

Then the White-Hat proceeds to do their work, writes a report and makes suggestions to the customer on how to improve the security of their system.

Simplified, a White-Hat is a Hacker you hire to test your systems.

What is a Black-Hat Hacker?

A Black-Hat Hacker (henceforth called "Black-Hat") does not have an aforementioned "Permission to Attack" and tries to find vulnerabilities wherever they can. Since their "work" is not backed by any legal grounds, they don't need to worry about playing by the rules, collateral damage, etc.

Black-Hats can have various motivations. The overwhelming majority does it for monetary gain, although others can be in it "for teh lulz", for political reasons or for their own personal convictions.

Simplified, a Black-Hat Hacker is a Hacker that tries to exploit vulnerabilities without any legal basis to do so.

I've been contacted by a person claiming to be a White-Hat regarding a vulnerability. Is it a scam?

Not necessarily. Some products or programs reside "offline" and are thus owned by the White-Hat Hacker. I don't need permission of a lock manufacturer to pick a bike lock that I bought from them. (I do however need permission of the owned of that individual lock!) If I found a design flaw in said lock, I can contact the manufacturer and inform them of said vulnerability.

Similarly, I could buy a product and analyze it. If I found a vulnerability, then contacting the vendor through a responsible disclosure procedure would be the only ethical thing to do.

However, in such cases it always has to be asked "Who's system was attacked?". In case of the bike lock, it is clear. I owned the lock, hence I can attack it. With software, especially cloud-based applications, the issue of ownership becomes much more complicated.

I stick to the rule "When in doubt, call an expert!" and in this case an expert would be a lawyer.

To summarize the question, "It's not always a scam and could be an attempt at responsible disclosure. Proceed carefully."


RdRand from /dev/random "Linus Torvalds, in response to a petition on Change.org to remove
  RdRand from /dev/random, has lambasted the petitioner by called him
  ignorant for not understanding the code in Linux Kernel. Kyle Condon
  from UK raised a petition on Change.org to get Linus to remove RdRand
  from /dev/random in a bid 'to improve the overall security of the
  linux kernel.'

What is the problem with RdRand from /dev/random?

It's a hardware implementation that hasn't been tested formally, and it's proprietary. The potential worry is that Intel could have backdoored the implementation at the NSA's demand.

The current way of mixing the rdrand output into the Linux kernel PRNG is that it's xor'ed into the pool, which mathematically means that there's no possible way for a weak output from the rdrand implementation to weaken the overall pool - it will either strengthen it or do nothing to the security.

However, the real risk is that the xor instruction is backdoored in a way that detects for the use of rdrand in a special scenario, then produces a different output when xor is called, causing only the purposefully weakened rdrand output to be placed into the pool.

Feasible? Yes. Plausible? Given recent revelations, maybe. If it is backdoored, is Linus complicit in it? Your guess is as good as mine.

Also, there's a great paper [PDF] on hiding hardware backdoors at transistor level in CPUs.

Edit, Feb 2019. User Luc commented below that things have changed since this answer was originally written:

  As of Linux 4.19, the kernel trusts RDRAND to seed its CSPRNG fully, unless one passes the random.trust_cpu=0 flag on boot (or sets it compile time). This should not be an issue if this is not your first boot, but newly installed systems or newly created VMs might have a predictable startup seed file (or no seed file at all), so for those systems this is relevant to gather good entropy.


Python security hardening I’m working for a large organization which is using some Windows products that require python to work.

Python is used to execute built in utility scripts and the user never recognizes that python is involved, Since the security requirements of the system are quite strict we are trying to lock down python as much as possible. We normally don’t allow normal users to use compilers or interpreters since it’s not allowed to add applications or functionality to the system. So we are looking for tips about how to restrict python so that only some scripts are allowed to run while the interactive prompt/interpreter is not available.

Is that even possible?

Our first approach was looking into restricting python with group policies, but that is not easily done since Python is not “GPO aware”.
Using software restriction policies are basically a block Python for all or allow Python for all.

Since python scripts are run through the interpreter (python.exe), the GPO software restriction settings for executable locations only checks the python.exe and not the script location itself (the GPO system only sees the python script as a generic argument to the python.exe executable).

So my question is: if anyone has have any experience in tightening the security concerning python? One again, our goal is that only some scripts are allowed to run while the interactive prompt/interpreter is not available, Is that even possible?

You could turn your python scripts into windows executables using py2exe. That way it would be treated the same way you restrict other system binary. Be aware that it is possible to reverse-engineer by "uncompiling" it, showing the script functions and all. But as your question in only about enforcing execution authorization, i think that it will fulfill your need.


Is it possible to have a man in the middle with SOCK5? If I am entering a password in facebook.com, an attacker in my subnet can build a man-in-the-middle attack with arpspoof and nat iptables rules by turning my HTTPS connections into HTTP and get my facebook password.

1. Is it still the case if I am using SOCK5 in the case of logging in through tor browser for instance?

2. Is there any man-in-the-middle variant allowing to catch passwords with SOCKS5 proxified connection?

Proxy servers would provide no protection against a MITM attack, since your attacker could MITM your connection to the proxy, or the proxies connection to the internet.

  by turning my HTTPS connections into HTTP

The bit about arp poisoning is correct.  Your assumptions about HTTPS are a bit misguided.  It is designed to be used on an untrusted connection, and is not easiy downgraded to HTTP.  It provides authentication and encryption.

To enhance security disable weak HTTPS cyphersuites, and make sure that you type https://facebook.com into your browser.


802.11 Authentication/Association and WPA/WPA2 authentication (Four-way handshake) So I have read that 802.11 standard requires stations and APs to go through the authentication and association before communication can take place. I also know that WPA/WPA2 has its own authentication method which involves a 4-way handshake to construct the PTK out of the PMK.

I am guessing these are two different authentications that happen separately ? I just want to understand the order of events. Is it correct to say that once the initial 802.11 Authentication and Association are finished then the WPA/WPA2 authentication mechanism starts?

Thanks

WPA2 is just a commercial name for a complete implementation of the 802.11i specification (WPA implemented only a part of it as a temporary measure against WEP weakness).

802.11i is an amendment to the original 802.11 specification, which means that it replaced several part from it, the original content becoming deprecated and a new revision of the 802.11 being edited.

More specifically, 802.11i introduces the concept of Robust Security Network Association (RSNA), and distinguishes between pre-RSNA security algorithms (WEP and 802.11 entity association) and RSNA security algorithms (the more secured algorithms allowed by WPA2).

Your hardware and software may offer pre-RSNA and RSNA security, usually as drop down menu allowing to select either WEP, WPA or WPA2. Your configuration here will define which algorithm you use, but at a given time you will use only one of them, they are not cumulative and will not be used at the same time.

For more information, 802.11i amendment can be found here (as per the current subject you directly jump to the "Security" chapter), and all successive amendments have been merged in the reference 802.11 specification (including deprecation of TKIP, which after all was just a temporary solution designed for WPA).


Cracking a wpa2-psk wifi I'm cracking a wpa2-psk wifi with aircrack-ng. After popullating the *cap file I'll apply brute-force with john.

The question is:

What time is it recommend to run airodump-ng before killing it's process?

How many beacons should be there, and how does that affects the brute-force procedure?

What you're looking for with cracking WPA-PSKs is handshakes (clients joining the network), so the exact amount of time that you'll need to wait depends on how busy the network is.

As a tip you can run airocrack-ng on the cap files whilst you're capturing traffic and see if there are any handshakes listed for the network that you're interested in.

Also another way to speed things up is to lock airodump-ng onto the channel that the network you're interested in is using (using the --channel switch) as that way it won't hop around all the channels and you'll get more traffic that you're interested in.

Additionally if there are clients on the network but there's not a lot of joining activity you can use a deauthentication attack to speed things along.


Allowing customer to generate a secret key for securing RDS instance on AWS I have an microservice architecture running on AWS ECS cluster using Postgres and Node and there is this requirement that we need to somehow allow our client to lock our database with a secret key such that we the developer's should not be able to access the DB directly without their consent.

This sounds a bit weird but the project involves sensitive data and there are strict compliance requirements which need to be met and hence we need to allow them in someway by doing something or the other by means of which when my app runs it fetches the credentials from a service and uses them to access the db while i should not be able to do that.

I looked at couple of AWS services which might help me store secret credentials in a safe place such as the Parameter Store and encrypt the data using KMS. But i have no idea that is this thing possible at all using AWS services or by any other means.

Any help or pointers as to how should one go about implementing this idea ?

It really depends on your requirements as Vinay pointed out. However I can give you some options:

You setup an IAM role which allows to change the master password of the RDS instance. Whenever you start the server you set this credential via the application. The AWS account has to be configured in a way that the developers are not able to do that. Issues: You cannot easily access anymore the database instance. You may have some issues with the scaling since you do not want to that two instances changes the password at the same time.
You setup the developer users within the AWS account in a way that they are not able to change the password of the RDS instance. The application access an S3 bucket to which the developers do not have access to. However the application can read the data from the S3 bucket. You can do this by using IAM roles which you assign to the application EC2 instances. Within the bucket you store the RDS password. You may allow from within the application to change the password. This way you can setup the whole thing initially and allow the client to change it once (or more). This way you can lock yourself out.
Eventually you can setup on the network level with security groups rules which prevents an access from the outside and you prevent that the developers can access the environment. This is eventually problematic since you may need to access the environment since you need a way to maintain the EC2 instances.


Creating root CA to issue certificates programmatically I have to generate a self signed root CA and use it to issue to certificates programmatically. I am new to security and certificates and I think I am missing some pieces required to make the whole thing work together.

From my understanding, I need to generate a X509 certificate using Java keytool to act as root CA and then use it's private key to sign the new certificates that I am generating using Bouncy Castle at runtime.

I generated a new certificate using keytool and the following command:

keytool -genkey -keyalg RSA -alias selfsigned -keystore keystore.jks -storepass password -validity 360 -keysize 2048

When I tried reading this keystore and certificate programmatically, I found out that the private key of the certificate is not stored in the keystore or there was no way to read the private key.

I have the following questions:

How do I generate a root CA using keytool?
What should be the output format of the root CA so I can read the private key? Is my current approach of writing the cert to a keystore wrong?

I believe you're asking the wrong question.  The right question is "Should someone new to security be working on a root CA?" and the answer is "probably not."

It is highly likely that what you're doing will expose everyone who relies on your root CA to high risk of compromise.  This has been demostrated by mature companies like Dell (see, for example, http://www.computerworld.com/article/3008521/security/a-second-dangerous-dell-root-certificate-discovered.html)

There are lots of ways in which things go wrong, which are way beyond the scope of a S.SE question.


Looking to take a hotspot that is shared and create my own hotspot that can be firewalled What is the best way to take a wireless hotspot that is owned by someone else, create my own hotspot or VLAN to be able to Firewall / Not allow my devices to view the other individuals' devices?

I am already using a VPN, but I want to be able to create my own hotspot from another hotspot and firewall it or create another VLAN. Is this recommended? What do you recommend? Is a VPN enough? Attempting to accomplish this is redundant? Or could it be an extra layer of security?

I am already using a VPN, but I want to be able to create my own
  hotspot from another hotspot and firewall it or create another VLAN.
  Is this recommended? What do you recommend? Is a VPN enough?
  Attempting to accomplish this is redundant? Or could it be an extra
  layer of security?

Oh my, this is not going to achieve what you think it will. If I understood correctly, there are some kind of a shared wifi hotspot, to which you wish to connect, then reshare the connection it provides via additional wifi hotspot created by you in order to elevate a security posture of your network, right? Well, there are no point in doing so, as all the traffic will still be visible to the original owner, and he can take his sweet time to decrypt it (if VPN are being used, or whatnot) by acting as man in the middle (say, acting as a proxy, forcing you to use the certificates he provided and so on)


What additional mitigations are necessary due to "Continue where I left off"? I work with sensitive sites that handle financial information, my code protects more than four billion pounds of assets.

All of our sites have a logout button and in addition use HttpOnly, Secure, Session cookies to maintain a user's session.  Although we expect users to click the "Logout" button, we also anticipate that some users will not do this; as a result, we rely on the session cookies to be dropped when the user closes the browser.

Recently it has come to my attention that browsers don't always drop session cookies when you close them.  Chrome, specifically, has a "Resume where I left off" feature that persists session cookies after the browser is closed, and what's more this option is selected by default.  FireFox has a similar feature.

What additional mitigations have you implemented due to this feature?  We considered a few:

OnBeforeUnload/Unload/PageHide handler to drop cookies when the window is closed.  Unfortunately you can't drop HttpOnly cookies in this manner.
Very short session cookies that are continually refreshed (every 30 seconds or so) via script.  This has issues because some browsers (especially on phones and tablets) halt Javascript execution when a tab is inactive, so this would have the effect of dropping users when they alt tab or switch windows.
AJAX handlers to maintain a heartbeat with the server.  Again, this will not work when the tab is inactive.

Is any additional mitigation necessary?  Or is it buyer beware if you don't explicitly logout?  Curious what other IT professionals have done about it.

Note: We also use a persistent cookie with a ten-minute sliding window, and expire the session on the server side in ten minutes.  The point of this exercise is to mitigate malicious activity that occurs within the 10 minute window, e.g. if someone is watching you carefully in an internet cafe and takes over your workstation if you don't log out properly.

If your site is that sensitive, set a max cookie lifetime of 15 or 30 minutes, rather than lifetime of the browser session.  And it's always buyer beware if they are accessing your site from a public location and they don't log out.

This is what I see on any financial site I use, from banks to credit cards to anything else.

Edit: I suppose that's not entirely true.  On some sites, they do allow you to "register your computer"... essentially, allow you to bypass some part of the identity check once (or rather, perform additional identity checks before) you've passed it once from that terminal.  You might be able to use this method to allow longer lived cookies on a registered terminal, if the user chooses to do so.  But when it comes to financial applications, you best bet is always to give the user as little rope as possible with which to hang themselves.  Other types of applications are more forgiving.


SIP provider does not support SIPS I am considering signing up with a low-cost SIP provider which, according to a current white paper, does not (yet) support SIPS (Secure Session Initiation Protocol). I understand that this means that my SIP user name and password will have to be transmitted unencrypted over TCP whenever my soft phone registers to this provider.

Is this a red flag or a restriction that is fairly common among other (well-reputed) SIP providers as well?

Actually it is very common to not support SIPS.

  user name and password will have to be transmitted unencrypted

SIP uses Digest MD5 for authentication which is a challenge response protocol where the passwords are not transmitted in clear text. Thus cracking the password by sniffing the connection is not possible unless the attacker has access to a huge number of authentications done by the same user.  Brute forcing the password is usually more successful.

Using Digest authentication also means that the password need to be stored by the server in clear text or in some equivalent form or reversible encrypted, i.e. the usual one-way hashing is not possible.


How to brute-force a somewhat remembered aescrypt password? I have a file I encrypted with AES via aescrypt about 5 years ago.  I remember a lot of things about the password with several prefixes and suffixes.  I have experience as a programmer but not with brute forcing passwords.

How might I go about brute forcing my encrypted archive?

What I think I know is: I need a rainbow table (list of possible words) and some way to guide a tool to likely suffixes and special characters.

I don't know what tools would be ideal for this particular scenario nor do I know how they'd be set up.  I've been reading man pages on many of the tools available from Ubuntu's package management system but instructions are focused on different scenarios and I can't seem to find a way to indicate what I need to indicate.

If I were to program my own solution for it I know I can take the aescrypt command and pass a password guess right in on the command line.  If the password fails it returns a non zero exit status so that's easy enough to check with.  For performance I'd write it in Rust and have a crack at a threaded implementation.  But I don't know much beyond trying permutations as far as perhaps needing some other characters injected.

The rules for this password are simple.  There are two periods in it, up to 8 likely words intermixed with possible conjunctions in them, possible dashes or underscores, and possible abbreviations of those words.  If that should fail I'd want it to fall back to a normal brute force with a suffix attached.

That should give me the highest chance of retrieving my files.  I would really appreciate being pointed in the right direction for this with some getting started tips and outlined instruction.  Thank you so much!

I'm going to post what I've learned here for posterity.  I've found the way to do what I want, although I doubt I have the system power to complete the task.

The first thing I tried was all possible combinations of what my guesses would be.  First I wrote a Ruby script to generate that.

#!/usr/bin/env ruby

JOINERS = ['', '-', '_', ' ']
PREFIX = %w[words for prefix]
CONJUNCTION = ['and', nil]
OPTIONAL = %w[words for optional]
SUFFIX = %w[.tar.gz .tgz .tar.gz.aes .tgz.aes]

def permute collection, length = nil
  (1..(length || collection.length)).
    flat_map {|qty| collection.permutation(qty).to_a }
end

def prefixer
  permute(PREFIX, 3).each do |prf|
    yield prf
  end
end

def optionaler(pfx, j, s, cap = false)
  permute(OPTIONAL, 3).each do |opt|
    opt = opt.map(&:capitalize) if cap
    CONJUNCTION.each do |cj|
      puts [pfx.join(j), cj, opt.join(j)].compact.join(j) + s
    end
  end
end

SUFFIX.each do |s|
  JOINERS.each do |j|
    prefixer do |prf|
      puts prf.join(j) + s
      optionaler(prf, j, s)

      prf = prf.map(&:capitalize)
      puts prf.join(j) + s
      optionaler(prf, j, s, true)
    end
  end
end

I ran this script and the output gave me just shy of 500,000 entries. I then used my FishShell to iterate over each of those and try the password.

for password in (ruby script.rb)
  aescrypt -d -p $password encrypted_file.aes 2>/dev/null
end

None of those worked so I have to switch to brute force… which means I may never get it open.

So I learned how to use crunch as per Matthew's suggestion and in combination with xargs it's pretty awesome!

Since I'm running a shell command each time, which attempts to decrypt a file, I though disk drive IO might be a performance consideration so I've created a tmpfs file system folder to put the file in and operate everything from within RAM.

mkdir tmpfs
sudo mount -t tmpfs -o size=800M,mode=0755 tmpfs tmpfs/
cp encrypted_file.aes tmpfs/
cd tmpfs

And here's the first command I worked out.

crunch 3 26 abcdefhilmnoprstuvwyz0123456789\ -_. -d 1@ --stdout | \
xargs -r -P 4 -I PASSWORD bash -c \
"! aescrypt -d -p 'PASSWORD' encrypted_file.aes 2>/dev/null"

Here are the parts.  crunch generates all possibilities of the following parameters.  The first number is the minimum amount of characters, the next is the maximum.  After that is a character list to use for every attempt.  I've excluded characters which I'm certain aren't in it so the character list is shorter and the process will get done much more quickly.  Next I have -d 1@ which tells crunch that no two of the same characters will be next to each other.

Then I pipe it to xargs which is a nice tool generally used for streamed input data to be passed as a parameter to the following command/argument.  But in this case we're piping it in to a particular place with the -I option which determines which text to replace.  The -r option says not to run with empty input.  The -P 4 tells it to run 4 instances in parallel with four different parameters passed in (this takes advantage of all 4 cores on my system).  Using 4 cores instead of 1 shaves off about 60% of the cost in time.

Next I execute aescrypt via a bash command bash -c and the PASSWORD area is substituted with every individual input passed in.  The reason I start this with a bang (!) is because when aescrypt doesn't successfully decrypt a file it writes to STDERR and gives a failing exit status which will stop the entire command immediately.  The bang flips the result so that on every failure it will keep running but when the file finally gets decrypted it will negate the positive response and exit the loop because our work is done.

Notes

I realize this isn't the most performant way to go about it but I'm giving a good stab at it.  I'll provide some additional performance observances I've seen.

When using the xargs parallel parameter it doesn't matter how high you go you will still get the same performance as the number of cores you have.  But if you run multiple shells with xargs each asking for more cores than you have then you will slow down the performance of all of them as if you only had 1 core.

Since one of my best guesses is that the password ends in .tar.gz I split the task in half by changing the command above to use two cores and shortening the character list for the second command to not include gz or any numbers (because if the extension exists the numbers won't exist for this password) and I've substituted 'PASSWORD' to 'PASSWORD.tar.gz'.  The second command I also gave 2 parallel processes.

Because I was flying blind and I wondered what the progress was I looked into how to read what's going through pipes.  First you can get the PID for each crunch instance with pidof crunch.  Once you have that you can watch what's streaming through each individual PID with:

sudo strace -pPID_NUM_HERE -s99999 -e write

From here I could write down the progress, stop a crunch process, and restart the crunch command where I left off by adding a -s option for a start point.

Towards Better Performance

At two character passwords I get about 35 passwords tried per second, at 3 character passwords I get about 12 passwords tried per second.  Tested by putting time -v --output=somefile before the command above.  It's not fast.

I realize that using pipes, xargs, and bash to run these commands each have their own costs involved and it would be much more expedient for me to write an implementation in Rust to do exactly what's being done above.  I'll need to take the source code for AES Crypt and link the library in to Rust to call the C code directly.  And either do the same for crunch or just implement the parts I need by hand (the latter is probably better).

It will definitely be more performant if I take out all of the middleware shell stuff and just run pure Rust.  Heck if I could take advantage of my GPU that would be cool to.  But there's a bit of a learning curve for me to get there.

I hope this information has been useful for others.  Feel free to share answers just as enlightening as this one.  Thanks!

UPDATE

Ori asked if I had tested if a happy path would work as expected.  Turns out I didn't account for that in either case.  I've got an updated version of the FishShell script here which works with a happy path.

for password in (ruby script.rb)
  if test -s the_file
    break
  else
    aescrypt -d -p $password the_file.aes 2>/dev/null
  end
end

The test -s tests to see whether the file the_file is blank or not.  aescrypt will write an empty file of the same file name being decrypted without the .aes extension in the same directory.  It uses the same name for a successful decryption as well.  This should be taken into account in all scenarios.

Alright the new updated crunch and xargs code that will work is:

crunch 3 26 abcdefhilmnoprstuvwyz0123456789\ -_. -d 1@ --stdout | \
xargs -r -P 4 -I PASSWORD bash -c \
"! aescrypt -d -p 'PASSWORD' -o 'PASSWORD' encrypted_file.aes \
2>/dev/null; if [[ -s \"PASSWORD\" ]]; then exit 255; fi"

This names the output file whatever the current password is and if the file's not empty it exits for success.  I have tested this with an example and it works!

Hopefully I'll get my file decrypted now.

Update 9/22/2017: Program Written

I've written a multi-threaded AES file brute force decryption software called abrute.  You need to have aescrypt in the systems executable path for it to work.


Biometric device instead of password - signature security Lets assume that there is a bio-metric algorithm for user authentication which compares fingerprints with a user's signature saved in a database (comparing function is not important here). Next, there is a device with a fingerprint sensor and memory to hold the user's signature.
Now we have two options:

Put algorithm and signature on device - device does computing and sends to PC information about matching captured fingerprint with signature
Put signature only on device - device sends captured fingerprint and signature to PC which will run authentication algorithm

In each case data is encrypted and there is some security protocol used in communication.

The question is, which method is more secure?

I am not familiar with IT security but I see a risk with both methods. In case 2, someone may intercept the signature and crack its encryption. In case 1, I see a problem with a message sent to the PC. What information is needed to confirm that this message was from our device and that it contains a true matching response? Does connection encryption provide that information?

Generally, method 1 is more secure as it is possible to ensure the fingerprint image never leaves the scanner thus cannot be trivially copied via compromised software. Some anti-tampering technology can be employed to make it very expensive to try to extract data from the device.

Your concern about how the scanner proves to the computer that the actual fingerprint is scanned is normally done by making the device hold some secret. For example, when a fingerprint is enrolled, the scanner also agrees on the secret key with the host. Each time a user needs to be authenticated, the host will ask the device to perform some operation that is only possible with the knowledge of the secret.

Such a scanner is typically tied into some other security hardware (like a TPM on PCs or security co-process on phones) so that the correct fingerprint activates the security key for data encryption. All of these are handled outside the main CPU so data cannot be practically decrypted without the fingerprint.


Is it good idea to re-authenticate a user to access sensitive actions and data? In a web application there are several pages in which you have sensitvie data and actions like access controls or user management page. Is it a good idea to re-authenticate user to access those pages? If yes, should they be re-authenticated for each access or is it enough to re-authenticate once till the end of session. Is there any rule about it?

... pages in which you have sensitvie data and actions like access controls or user management page. Is it a good idea to re-authenticate user to access those pages?

From the standpoint of risk mitigation it is a good idea. From the standpoint of usability it is annoying when work flows too often get slowed down by the need for re-authentication.

Is there any rule about it?

The rule is to find the right balance between risk mitigation and usability. This is specific for each use case, i.e. what risks you actually need to address, what usability is necessary and what annoyances are acceptable etc. It might also depend on variations of the use case, i.e. risks might be different if users accessing the data is physically inside the company or if they are logged in from outside.


Best practices for Apache Server hardening? What are some best practices, recommendations, required reading for securing an Apache Server?

Grab the Center for Internet Security (CIS) guide for securing Apache (it describes in detail how to enhance the security):

Edit:  Updated link
CIS Apache HTTP Server 2.2.x Benchmark

If you have a license to Nessus, then you can run an automated check by grabbing their audit template:


Meterpreter session vs shell What is the meaning of "meterpreter session"? My understanding is it is a session that we can send commands to the host for execution. And a meterpreter session is created when we don't get a shell.

Meterpreter is one kind of shell. So, you can send commands in both a meterpreter session and a shell.
You configure the exploit to use what you want, either meterpreter or some other command shell. Metasploit doesn't decide that for you.


Does software based file recovey solutions have the same results on real physical device vs dd image file? I have a flash drive and I want to recover some files from it. Can I take a dd image of the device and perform the recovery operation on dd image instead? Does it have the same results when performing recovery using software on physical flash drive?

Yes!

It's standard forensic procedure to work from a "Physical Copy", which is what a dd bit-for-bit image is. It will have the same results as working from the drive. In fact the hash checks verify that they are the same.

This assumes of course that the dd image was done appropriately. An example of an inappropriate dd image would be one done against a multisession DVD as DVDs are not actually block devices and only the last session would be extracted.

A flash drive is a block device and would image as expected via a dd.

Wear leveling is a bugaboo that's often thrown around but it's not a factor here.

The one extremely unlikely difference with an SSD (Solid State Drive) is a massively delayed TRIM function. If the TRIM runs delayed by many minutes, a dd image may actually extract data before the TRIM runs quicker that performing the analysis directly against the SDD, in which case the image would be better but the hashes would not match causing problems. I've never seen this occur!


OCSP, CRLs, crlset - Revocation Delivery and Attacks OCSP responses have a 'nextUpdate' field, which is the expected time for the new revocation update and that the current revocation can be considered valid.  The revocations can be cached by the intermediate cert servers, which I have seen used in designs which provide stapled responses.  I have read that revocations are delivered immediately from the root CA to the intermediate CA.

In this case, what if there was a DoS attack to the root CA server so it is prevented from delivering the revocation?  This could expose a window of opportunity, using the intermediate server's cached revocation entry, that would incorrectly advise an end user's client that a website cert is valid, when may be invalid.  The user's client or browser could interact with a malicious site until the DoS is stopped, a phone call is made to all the intermediate servers, etc... up to 7 days.

There have been at least three DoS attacks on root name servers lasting at least an hour long, however I'm not sure how they would affect a CA server's ability to send outbound traffic.  Perhaps they have side channels of getting the revocation list out.

Does anyone have any more information on the technical aspects of this and the possibility of this type of attack occurring?  Also, I'm curious if anyone knows the caching infrastructure for CRLs and timing to expect a revocation to appear at a typical intermediate CA?

Chrome uses it's own propriety method of crawling CRLs and Google pushes them to the browser in chunks, called crlset.  At first glance, OCSP has a better timing advantage compared to crlset, because it contacts authorized responders directly to get the revocations status, however after finding that some providers have implemented variably defined CRL cache update periods, I'm not sure it's actually better.  Google claims that's their revocation list is updated daily and this is more frequent then other solutions.

Does anyone know the tradeoffs in security between OCSP and Google's crlset method?  Specifically which has better timing and reliability to get the revocation response?  Is Google's claim supported by evidence?

I asked a question about CRL and OCSP yesterday and then read up on it and I for one came to the conclusion that there is no "perfect" solution at the moment.

In a perfect system the browser would verify the revocation status at the CA itself at least once EVERY session but for that to work every CA would need to create huge server clusters with great redundant connections spanning around the world to ensure minimal response times.

Because that's not really feasable (you can't expect every CA to create such a big infrastructure) OCSP stapling was created in the first place with the downsides you stated.

Google's crlset is basically something in between, it acts as a CRL-cache. The upside is that Google has a huge server infrastructure in place that is less prone to DoS attacks, so in theory this is a good thing. The downside is that you are reliant on Google with all the privacy concerns and other problems that come with it.

In my opinion certificates should include a "mandatory revocation check on every request" boolean field which forces the client to update the revocation status on every request.
So basically critical infrastructure and high security applications like banking sites always enforce an up-to-date revocation status at the start of every session and less critical sites just don't and opt for usability instead of (higher) security. Also users should have the option to set this individually for every site (just like cookie options etc.) unless it is enforced by the server (so deactivating it when the server enforces it shouldn't be possible).

This is as much a political thing than a technical, it needs regulation to get something like this in place.

But then again, the attack vector for this scenario is pretty slim in reality if you think about it. Because basically you have to first attack the server and corrupt the certificate (which should be very unlikely for high security applications) AND simultaniously DoS the root CA with a huge attack so nothing comes through and then use that small window to perform your attack, this is very, very unlikely and can be migitated even more if the nextUpdate period was even smaller (which it should be in high security environments).

So it's also a matter of "Who is responsible for the integrity of a server?" because when someone gets hold of your server's private key, the revocation status of your certificate isn't exactly the biggest problem you have but some one having root access to your server (or even worse getting your key without root access).


How to discover GET/POST parameters used in URL during pentest? Is there a good/systematic way to discover the GET/POST parameters used in the URL?

For example, I want to discover the parameter names a, b, c used in the URLs

https://myserver/index.php?a=10
https://myserver/index.php?b=test
https://myserver/index.php?c=hello

you can only discover parameters used by developer and serving to you, in this case if you want to discover all GET/POST parameter of the page you should analyse the code of this page, no way to discover all parameters after compile.