Is a non-authenticated CSRF still a CSRF? OWASP defines Cross-Site Request Forgery (CSRF) as

  an attack that forces an end user to execute unwanted actions on a web
  application in which they're currently authenticated.

(emphasis mine)

An example of attack is the link http://example.com/logout sent to an authenticated user who, upon clicking it, is logged out. We managed to change the state of the system (in that case - user login) by making the user click on a link we provided him.

Now imagine a voting system where everyone can vote, no matter whether they are authenticated or not. The system does not keep track of who voted (which is on itself obviously an issue).

I can replay without limitations HTTP calls which will increase the voting counter. Would sending that replay link to someone else who would (without being logged in) click on it and increase the voting counter be considered as an CSRF vulnerability?

My opinion is that this is not a CSRF because:

we lack the "authenticated" part of the definition (that would be for the semantics)
I believe that the intent of this classification was to highlight that an attacker can make you execute commands he otherwise could not do (because you need to be authenticated). The case of the non-authenticated vote above is IMO better described by A4 (Broken Access Control)

Would sending that replay link to someone else who would (without being logged in) click on it and increase the voting counter be considered as an CSRF vulnerability?

Checking the 2013 OWASP entry on CSRF, their attack scenario (to my mind) seems to describe something similar to your example:

  The application allows a user to submit a state changing request that does not include anything secret.
  So, the attacker constructs a request that will transfer money from the victim’s account to the attacker’s account, and then embeds this attack in an image request or iframe stored on various sites under the attacker’s control

In the case of your example, because no authentication is required, that scenario holds true in all cases: an attacker can cause a user to issue a request against your site, which will cause a state change.

I think OWASP's mention of the session being authenticated reflects an assumption on their part about what would be required to effect state changes on a site.
I don't think the authentication is in fact part of the definition of CSRF - the wikipedia entry on CSRF mentions:

  CSRF commonly has the following characteristics:

  It involves sites that rely on a user's identity.
  It exploits the site's trust in that identity.
  It tricks the user's browser into sending HTTP requests to a target site.
  It involves HTTP requests that have side effects.

So I think you could in fact consider your application to be vulnerable to CSRF: a user can be compelled to issue a request with side effects, and that request will always succeed (and could, at least in theory, be tied to the user's IP, for example).

I am not sure CSRF is purely about allowing an attacker to 'do something they could not otherwise' - I think one could argue it is about making a user do something they may not have done otherwise.


VPN as a firewall in a public network My configuration is: allow only OpenVpn traffic and block any other (income/outcome) traffic with UFW on my ubuntu laptop.

unreal scenario: let’s say i have ubuntu with chrome version 50 [2016] on it connected to a public Wifi . Would attackers on the public wifi would be able to exploit my Laptop or would they have to compromise my VPN server first ?

A VPN is not a firewall by itself but only a virtual tunnel which has another public IP  on the tunnel endpoint than your systems current public IP. A VPN by its own offers no protection against attacks, it protects only the communication between the tunnel endpoints against sniffing and manipulation.

Thus, the attacker would not need to hack your VPN in order to access your system. It only has to attack the tunnel endpoints IP address instead of your systems public IP address and the VPN will forward these attacks through the tunnel to your system.

Of course a VPN might be combined with a firewall or NAT and would offer some protection this way - but this is then a property of the firewall or NAT and not of the VPN.


How can the Google web crawler bypass portals? This is a situation that I have encountered on a number of occasions. I will conduct a web search in Google, a link to a file (.pdf for example) will take you to that file on the server. It opens up in your browser, you can save the file.

But when you backtrack through the URL to find out more about the website that holds it, and if there is other information that can aid your search, you are denied access. You are either given an error message or taken to the log in page for a web portal. Which can be accounted for by configuring the server to prevent directory traversal.

While I understand the lack of a robot.txt file could contribute to this, some of these sites would not rely on these for protection since a rogue web crawler would just ignore the file anyway. Not to mention the robot.txt would enumerate a lot of your files and directory structure to a hacker.

So it would be too much to presume that some of these sites were not protected by physical firewalls, and given the server authentication which denied moving to other parts of the site, that crawling the site could be done without having log in credentials.

So what loop holes is the Google crawler exploiting that allows it to bypass possible firewall, server authentication, and portal protection to find out the directory structure of that server and create direct links that allow someone without credentials to see that file?

I some times get the illusion that GoogleBot has special access to the directory structure but that doesn't mean that there is a loophole or a vulnerability.

Some of the reasons for that illusion:

The links might be from outside of the website. I can post on my blog a link to a Pastebin that is not listed anywhere on pastebin.com.
The pages that had the links to your documents might have been deleted or hidden but Google still has the link to the file.
The sitemap file can have a list of links to the files on that website.
The owner of the website can use Google Webmaster Tools and load a list of links on the website.
Something that is almost but not quite a vulnerability is that GoogleBot decompiles flash resources and indexes text and links found there.
It can also execute JavaScript and parse Ajax content.
There is a new Googlebot user agent that looks for mobile content. The mobile interface can be missconfigured to show more information and have more access than the classic one.
As others commented, websites can provide more or different details when the visiting IP or user agent indicates Googlebot. This is called clocking and is not tolerated by Google or any other search engine.

Googlebot has simple rules, it follows links and respects the robots.txt file and the nofollow tag. It indexes information that has to be accessible to Google's users and not break the security or privacy of the crawled websites. If there is anything that indicates otherwise, then I suspect there is a website missconfiguration rather than Googlebot malice or magic.


AES CBC over TCP - when is new IV needed I am working on a project where two devices will be communicating with AES with CBC over TCP.
We already have a secure mechanism for sharing the encryption/decryption key.
I am not sure if we need to have a random IV or not, or how often to begin a new "message".

Here is how I think it will work:

Both sides send hello messages to each other to signal the start of the channel. Each side's message will start with a random IV.
After that point each side will occasionally send a small message to the other which will be chained off of the previous messages. This will likely continue for a few minutes but could go on indefinitely.

Does that work? Does each message need a new IV? Each potential session will have a new encryption key, so are random IVs required?

There are three points to be made, I think:

Do not build your own protocols ! Or, at least, do not believe the result to be secure. Otherwise, stick to well-studied protocols, like SSL. If your goal is to learn, then go on.
In CBC, the IV (or previous block) must be unpredictible for the attacker. Consider SSL, where data is split into records (that's your "messages"). Each record is sent atomically. In SSL 3.0 and TLS 1.0, the last block of a record is also the IV for the next record; this means that an attacker observing the stream and being able to input some data of his own in the cleartext stream can observe a record, learn the IV for the next record, and then compute the cleartext data he wants to insert in the next record. That's the basis for the BEAST attack which was published last year for SSL (actually an older attack, but NEAST is about make it plausible in HTTPS context). So, to sum up: you must choose a new, random IV (with a cryptographically strong generator) whenever you are about to encrypt plaintext data which was obtained after having sent over the wire the previous encrypted block.
You need an integrity check; otherwise, an attacker could modify your messages, and beside the obvious problem of using corrupted data, this can endanger their confidentiality as well. Do yourself a favour and use an encryption mode which includes integrity, e.g. EAX. This makes the problem quite simpler:

The IV need no longer to be unpredictible, only non-repeating. A simple counter will do.
You need a new IV whenever you start a new message.
By construction, the receiver cannot process a message without having received it completely (because its contents cannot be trusted until the integrity has been checked). So your incentive for breaking data into messages is to limit RAM usage on the receiver; and you need to close the current message whenever you want to "flush" the data.

The old-style way to add integrity is to use an independent MAC construction (such as HMAC) but combining symmetric encryption and a MAC can be tricky (see this question for details) so you'd better use EAX (or something equivalent like GCM).


How to reverse engineer password from /etc/shadow I failed to answer a question in a CaptureTheFlag event, and the the question still bugs me. I want to share the question here and please help me if you know the solution.

Question:
You have the shadow file form a linux machine. Please find the admin password.
And the content of the shadow file is

root:*:17277:0:99999:7:::
daemon:*:17272:0:99999:7:::
bin:*:17272:0:99999:7:::
sys:*:17272:0:99999:7:::
sync:*:17272:0:99999:7:::
games:*:17272:0:99999:7:::
man:*:17272:0:99999:7:::
lp:*:17272:0:99999:7:::
mail:*:17272:0:99999:7:::
news:*:17272:0:99999:7:::
uucp:*:17272:0:99999:7:::
proxy:*:17272:0:99999:7:::
www-data:*:17272:0:99999:7:::
backup:*:17272:0:99999:7:::
list:*:17272:0:99999:7:::
irc:*:17272:0:99999:7:::
gnats:*:17272:0:99999:7:::
nobody:*:17272:0:99999:7:::
avahi:*:17272:0:99999:7:::
sshd:*:17272:0:99999:7:::
admin:$6$/iIQV39h$ZpQpavCJ5xo2GshqMtkSMsBxaGA9WBwqmtBwyszeE9zdy9546eBb45LdqKyF9/BE3nAS.w/26dJBZ74mDB2Kl/:17401:0:99999:7:::

From the available information, I figured out that the password is hashed using SHA512 with a salt.

Since SHA512 is a pretty strong one-way hash algorithm, I don't know to to reverse engineer the password.

(There must be a correct answer to this question, because some other event participants answered correctly.)

A bruteforce attack using JTR shows the password as qwertyuiop.

root@pro5:~/hack# john file.txt
Loaded 1 password hash (crypt, generic crypt(3) [?/32])
Press 'q' or Ctrl-C to abort, almost any other key for status
0g 0:00:00:14 40% 1/3 0g/s 67.89p/s 67.89c/s 67.89C/s :99999..DrAdmin
qwertyuiop       (admin)
1g 0:00:01:15 100% 2/3 0.01325g/s 68.11p/s 68.11c/s 68.11C/s samsung..britney
Use the "--show" option to display all of the cracked passwords reliably
Session completed
root@proc5:~/hack#

It cracked the password in less than 5 minutes with my old Pc as it is a weak password. If the password is strong it will take more time to crack it.


SSL - Null Prefix Attacks Still Possible? At DEFCON 17 (2009) Moxie Marlinspike  gave a talk were he was able to use a malformed certificate signing request to get SSL certs signed for domains he doesn't own. The gist of it was that for the common name put something like www.bank.com\0.iownthisdomain.com with \0 being a null byte.

Is this attack still generally possible, of course you can probably find CAs that are still vulnerable but are the clients, particularly Microsoft's SSL stack?

Microsoft has issued the MS09-056 update which patched this vulnerability in CryptoAPI on almost all of their operating systems, that automatically fixes it for Internet Explorer, Chrome, Safari, and any other application that relies on the CryptoAPI. Mozilla has issued an updated quickly after Marlinspike's demonstration and Opera has patched it in version 10.00


Which CRL should an intermediate CA crlDistributionPoint contain? Given a root certificate authority (CA) and an intermediate CA signed by the root:

Which CRL should the crlDistributionPoints contain to for the intermediate CA? The root CA's CRL or the intermediate CA's CRL?
It makes sense that each certificate should point to the CRL of the CA that signed it.

Which CRL should the root CA contain, if any?
It would seem that since it is self-signed, it should point to it's own CRL.

Should user or server certificates signed by the intermediate CA point to the intermediate CA's CRL, or both the intermediate's and the root's CRLs?

Please cite the RFC if you can. I can't find a clear answer there myself.
Asked another way, where would a client look for a CRL to see if a given certificate has been revoked? In the certificate itself or in the signing CA's certificate?

Which CRL should the crlDistributionPoints contain to for the intermediate CA? The root CA's CRL or the intermediate CA's CRL?

The crlDistributionPoints must point to the CRL which will contain the revocation for the certificate itself. Thus in case of an intermediate CA this will probably be the CRL signed by the issuer CA, although it can be any other CA as long as a trust path can be constructed.

  Which CRL should the root CA contain, if any?

The root CA can not be revoked. Trust for the root CA is not established through certificates but because it is integrated as pre-trusted in the browser or OS. This means if the root CA gets corrupted it must be removed from the browser/OS without any kind of CRL mechanism.

  Should user or server certificates signed by the intermediate CA point to the intermediate CA's ...

Again, they should point to the CRL which will eventually contain the revocation record. Which CRL this is depends on how the revocation is implemented at the CA.

  where would a client look for a CRL to see if a given certificate has been revoked?....

The client looks into the possible revoked certificate and extracts the crlDistributionPoints from inside this certificate. Then it downloads the CRL from this point and checks if it contains the serial number of the certificate.


Does preventing buffer overflow attacks prevent ROP attacks? Would preventing buffer overflow attacks prevent Return Oriented Programming (ROP) attacks?

A quick Google search says "no". The original paper from the original presentation (Section 4.2) says that although Buffer Overflow is easiest, it is not necessary.

  However, a stack overflow isn’t necessary. The payload containing the
  return-oriented program could be on the heap, and the attacker could
  trigger its execution by overwriting a function pointer with the
  address of a code snippet that sets %esp to the address of the first
  gadget and executes a return.


Does adding two-factor authentication by OTP really make KeePass more secure KeePass is an application that keeps all your passwords for you in a database. It is primarily protected by a master password and/or keyfile. If the database is properly encrypted with that password this can be quite secure.

There is a plugin OtpKeyProv that supposedly increases security by adding a second authentication factor. After protecting your database using this plugin, you need to generate and enter one-time passwords in order to open your database.

My question: does this really increase security? I see no way how the OTP mechanism can be used to further encrypt the database. Can't a hacker that gets hold of the database not simply compile a version of KeePass (it is open source) that does not ask for the OTP value?

As far as I can see the plugin only annoys you when you want to access the application, leading to a false sense of extra security.

Or am I overlooking something.

No. Security remains the same + extra cognitive overhead.

Presumably the plugin uses OATH HOTP where the KeePass file or master key is re-encypted after each access with the next one-time-password.

However to generate the next password on the device, the plugin would require either a secret stored on the device or the normal password for the KeePass file.

Security from a one-time-password comes from two parties knowing the same key and counter - HOTP(Key,Counter) - while an attacker doesn't know the key. If the attacker has access the device storing the KeePass installation and files, the security re-collapses to the security of the normal password on its own. If the KeePass file is still interoperable with other KeePass programs, then you gain nothing from using a one-time-password in this fashion.

One-time-passwords work well for server authentication because both client and server end-points are considered secure and the attacker needs 'something you own' as well as 'something you know'. If the attacker has your computer, then they now have 'the thing you own'.


Can malware be attached to an image? I have a small number of employees who use a company computer but these people aren't very tech savvy. They use an email client and a messaging client.

I'm pretty sure they wouldn't click on .exe or .zip file in an email without thinking, and I know that's one area of concern.

However, I'm thinking about images. In fact, regardless of how capable a person is with technology I believe that attaching things (code or anything else) to an image can be a security risk.

What can be attached to images to harm another?

I believe that images can pose a security risk as they 'automatically execute' or something.

There are so many ways that images can be received by a computer (including phone or tablet of course):

- email
- iMessage (or any other messaging app)
- someone right-clicking and saving an image from a web page
- just viewing a web page of course downloads the image to cache

What precautions do I need to take regarding the above four things? Can someone just attach some code to an image and it execute?

What do I need to do to prevent images being used against my computers?

I'm guessing you couldn't just attach code to an image and iMessage someone's iPhone. What about Android?

The other answers mostly talk about attaching arbitrary code to images via steganographic techniques, but that's not very interesting since it requires that the user be complicit in extracting and executing that.  The user could just execute malicious code directly if that's their goal.

Really you're interested in whether there's a possibility of unexpected, arbitrary code execution when viewing an image.  And yes, there is such a possibility of an attacker constructing a malicious image (or something that claims to be an image) that targets specific image viewing implementations with known flaws.  For example, if an image viewer allocates a buffer and computes the necessary buffer size from a naive width * height * bytes_per_pixel calculation, a malicious image could report dimensions sufficiently large to cause the above calculation to overflow, then causing the viewer to allocate a smaller buffer than expected, then allowing for a buffer overflow attack when data is read into it.

Specific examples:

http://technet.microsoft.com/en-us/security/bulletin/ms05-009
http://technet.microsoft.com/en-us/security/bulletin/ms04-028
http://www.adobe.com/support/security/bulletins/apsb11-22.html
https://www.mozilla.org/security/announce/2012/mfsa2012-92.html
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2010-1205
http://en.wikipedia.org/wiki/Windows_Metafile_vulnerability

In general, these sorts of things are difficult to protect against.  Some things you can do:

Keep your systems and applications updated.
Enable DEP.
Enable ASLR if possible.
Avoid running programs with administrative privileges.
On Windows, Microsoft's EMET could also provide some protection.


Notice of Credit Card Fraud via text on my phone someone responded how did they do it? I received a text alert from Capital One fraud alerting me of unusual activity someone replied to the text confirming the activity. I have an Iphone. How can they get access to my phone and what do I need to do to secure it? I've called Capital One and card is inactive my primary question is.. do I have some sort of malware on my phone?  Can I search it?  How do I secure my phone?  Any help would be greatly appreciated thank you

Your iPhone (assuming its relatively current) can perform SMS relaying, sending/receiving messages using the iMessage app, on other devices that are logged in to your account.  You should check your associated devices via the Apple web site to ensure there are no unknown devices listed and remove them if there are.

Assuming you are not using a jailbroken iPhone your apps should be safe, but to be sure you should review all the installed apps on your phone for any that were recently installed that you don't recognize.


What's the difference between a hashed and an encrypted password? Alright, so I know this may sound dumb, but I'm having a hard time understanding what an encryption would be since it's different from a hash. I've read up on it, but I'm still not quite sure. So, I was hoping you guys could help me with it.

Encryption vs. Hashing

Nobody really "encrypts" a password, although you could... but you'd be encrypting it with another password, and you would need that password to decrypt the first password. When it comes to passwords, we normally hash them.

Hashing is simply one-way. You cannot get the string back, you can only check to see if a string validates against a hash. If your string validates against the hash, this does not guarantee that it's the same "password," but you can log in with it because you've found a collision. The "message"/password is usually limited to a small number of characters, relatively speaking.
Encrypting is two-way. For example, you have an algorithm, a key, and a message. Using the key, you can unlock the message. Usually, the message could be of arbitrary size.

Makeshift Flowchart Examples

I made a couple flowcharts that are overly simplified. Hope it helps.

See the above? It doesn't make any sense that you would get the "message" back. Why? You're already entering the password, which is the "message" itself.

Now look at this:

With encryption, you're getting the decrypted message back if the decryption key is correct. You use the key to unlock the encrypted contents.

With hashing, you already have the "message" if it validates, or a collision. What you enter is the message.


Should I tell my boss I have discovered their passwords and they are too weak? I'm on a temporary job so they don't give me any passwords to access the sites and resources I need. Instead, they tell me to move to another computer where a regular employee is and where every password is already set and saved on the browser.

I have to be honest, I got into the router (as they are using default credentials) to get the WiFi password so I can use it on my phone and found that it had a lot to do with the activity the company does (e.g. if they were a restaurant, their password would be coffe123). With that in mind, I just wanted to see if the same pattern was used for other types of resources such as the email address, hosting accounts, etc. and yes, they were.

When registering another domain with a new account, I guessed the password by seeing my boss slowly typing on the keyboard and, again, weak as f*.

Should I tell them? I'm afraid I might get in trouble for lurking too much.

Just as a clarification: it's not a big company, we are just a few employees and none of them but me know about computers and security, so there's no way of anonimously reporting the issue or contacting a sysadmin or IT related guy.

While there is no doubt that weak passwords are an issue for your company, I would strongly advise against telling your boss about the things that you have done.

Your company decided against giving temporary workers access to sites and resources for a reason. Not only did you gain unauthorized access to the wireless LAN by guessing the password to the router, you also extended that access by probing the credentials against other resources - Resources that you were not supposed to have the password to. You then basically shoulder surfed your boss.

While there seem to be flaws in your employers policy concerning the access to company resources, and their password policies, all of these things could be considered 'hacking' by your employer and were definitely outside of your authorization.

If I were you I would log off the WLAN and ask your employer for the password if you want to have access to it. Apart from that you should stop trying to use other peoples passwords on any access points just 'to see if the same pattern was used'. Depending on the legal system of the involved countries you can very well face legal problems for these kinds of acts.

So what should you do with the information you have?
If your employer gives you a password to a service or a resource you could point out, that e.g. that password would easily be guessable for other people. I would not mention the other password here directly though.
If your boss seems interested you could volunteer to research password best practices for the company. If they are serious about it, this would eliminate your concerns.
If there is an IT person in the company you could bring these concerns to him as he will probably understand the need for a secure password policy better.


Whenever an unhandled exception somehow makes it into production, is it safe, viable, etc. to print an encrypted stack trace to the end user? Whenever an unhandled exception makes it into production somehow - whatever the reason - there's generally an option (especially with .NET programs) to print out a stack trace to the end user before the program ends completely.  Even though this helps with debugging the program, if the user sends a copy of the stack trace in a bug report, it is definitely a security concern.  You don't want them being able to see your code like that - not without them going through a lot of extra hassle.

But what if the text of the stack trace were encrypted before being printed to the screen?  Would this be something which is safe, viable, etc.?  Or would it still be something particularly worth avoiding?

NOTE

I'm aware of decompilation and the issues that produces.  There are obfuscators though, and even though they're pretty much anything but perfect, they are better than no protection at all.  It has been said that locks are for honest people, but everybody still uses them.

Think about why you want to do this. It is in my opinion, entirely pointless.

If the exception occurred on the server side, handle and log it there. There is absolutely no point in displaying the stack trace to the user.

If the exception occurred on the client side, in a thick client style web app, desktop app, mobile app etc, there is absolutely no point in encrypting it. Any determined enough user can decompile or reverse engineer client side code. In fact, how would you encrypt the data? Encryption implies an encryption key, and this key has to be stored somewhere.

I also question what a normal user can do when you display the stack trace. If crash data is important information, implement some sort of reporting functionality for diagnostics.


two factor authentication without TLS/SSL It seems silly to ask about using two-factor authentication without TLS/SSL but, I have a vendor that is using public IP without TLS and asking for login creds.

Would the login be more secure if two-factor authentication was enabled without TLS?

Using something like Google Authenticator and, knowing the keys are ephemeral the window for stealing the credentials would be about <30 seconds, correct?  It seems a bit more secure but not by much.  What are your thoughts?

2FA will decrease the chance that an attacker can steal a complete set of login credentials because, as you point out, the second factor is likely limited by lifetime or a once-use policy.

But 2FA will not affect snooping or session hijacking. So, while an attacker may find it more difficult to login as you, they can watch your communication stream and send messages that appear to be from your session.

Besides providing confidentiality, SSL also ensures that you are actually talking to the server. Without SSL, a MiTM attack can pretend to be the server. For example, you can try to logout from the server to kill your session but a MiTM can intercept the logout command and return you to a page that makes it looked like you were logged out though you really weren't.

So it may prevent future false login attempts but doesn't really make you secure at all.


GnuPG: How to create ECDSA signature? https://tools.ietf.org/html/rfc6637 defines ECDSA for OpenPGP and https://wiki.gnupg.org/ECC lists elliptic curve support in GnuPG since version 2.1
I have version 2.2.25 and it lists ECDSA as supported algorithm:
$ gpg --version
gpg (GnuPG) 2.2.25-unknown
libgcrypt 1.8.7
Copyright (C) 2020 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <https://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

Home: /c/Users/Matthias/.gnupg
Supported algorithms:
Pubkey: RSA, ELG, DSA, ECDH, ECDSA, EDDSA
Cipher: IDEA, 3DES, CAST5, BLOWFISH, AES, AES192, AES256, TWOFISH,
        CAMELLIA128, CAMELLIA192, CAMELLIA256
Hash: SHA1, RIPEMD160, SHA256, SHA384, SHA512, SHA224
Compression: Uncompressed, ZIP, ZLIB, BZIP2

However, if I generate a key, I'm not presented with that option:
$ gpg --full-generate-key
gpg (GnuPG) 2.2.25-unknown; Copyright (C) 2020 Free Software Foundation, Inc.
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

Please select what kind of key you want:
   (1) RSA and RSA (default)
   (2) DSA and Elgamal
   (3) DSA (sign only)
   (4) RSA (sign only)
  (14) Existing key from card
Your selection?

How do I generate an ECDSA signature using GPG?

okay, seems one has to add the --expert flag:
$ gpg --full-generate-key --expert                                                    gpg (GnuPG) 2.2.25-unknown; Copyright (C) 2020 Free Software Foundation, Inc.
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

Please select what kind of key you want:
   (1) RSA and RSA (default)
   (2) DSA and Elgamal
   (3) DSA (sign only)
   (4) RSA (sign only)
   (7) DSA (set your own capabilities)
   (8) RSA (set your own capabilities)
   (9) ECC and ECC
  (10) ECC (sign only)
  (11) ECC (set your own capabilities)
  (13) Existing key
  (14) Existing key from card
Your selection? 9
Please select which elliptic curve you want:
   (1) Curve 25519
   (3) NIST P-256
   (4) NIST P-384
   (5) NIST P-521
   (9) secp256k1
Your selection?


Investigating HP sure start triggering security warnings The following question belongs more to the HP forums but unfortunately I am not gaining any traction there. Please move the question to another SE if its off topic for this community.
Recently I've started receiving the following BIOS interruption & message at each boot:

"HP Sure Start detected an unauthorized change to the Secure Boot
Keys. The key was restored automatically and there is no further
action required. The repeated occurrence of this problem indicates a
security problem should not be ignored."

See screenshot at the bottom.
I have no idea what is causing this warning. I recall recently updating Zoom and perhaps a routine Ubuntu update, but nothing else.
I am using the laptop for security critical interactions so I want to make sure I understand what is causing this and how to get to the bottom of it.
Any idea how I could investigate what is changing Secure Boot keys and why? What exactly could be the trigger for such warning? How can this be investigated further and resolved?
I am running Ubuntu 20.04.1 LTS.

Looks like something is updating your trusted keys in UEFI (if your are using BIOS or "legacy", please switch to UEFI). This might come from the Ubuntu OS (or not).
Have you updated the firmware of your motherboard? Have you set an admin password on your BIOS/UEFI? If not, please do both then come back if this did not solve your issue.
Also, this question might be more suited to a chat on the DMZ, or should be asked on superuser.com or unix.stackexchange.com.


How to use TPM to perform platform authentication? I am currently looking at TPM (Trusted Platform Module) and wondering how does TPM offer platform authentication. Suppose a legal host is deployed on the cloud. How do I use TPM to assure that the host I am connecting to is that very host, rather than some other host that has the same configuration?

In principle, since that very host is equipped with TPM, whose Endorsement Key is unique, I can verify it via the public key of EK (Endorsement Key). For example, I can have TPM to encrypt a message with its private key of EK. And I decrypt it with the public key of EK. However, I looked up the documents, and didn't find any API to explicitly encrypt arbitrary message with private key of EK.

So, usually, how can TPM be used to perform such host authentication?

What you need is remote attestation (QUOTE operation).

The Endorsement Key (EK) is not directly accessible as this would be privacy issue - we could track a system using this unique identifier. The EK can be used in conjunction with an Attestation Identity Key (AIK) or using Direct Anonymous Attestation (DAA).

The AIK model make use of a Privacy CA (Certificate Authority) which assert the validity of your EK to a third party. Multiple AIKs can be created to protect your identity (e.g. one AIK per thrid party, one AIK per security domain).
The DAA model use 'Zero-knowledge proof' to anonymously verify your EK. See this to get a general idea how zero-knowledge protocols works.

I suggest you take a look at OpenAttestation open-source solution from Intel, PrivateCA and this presentation.


Why would someone submit loads of email addresses to a form that does nothing? I operate a simple lead-generation website for a friend, consisting of a single page with an HTML form with just one field: email address.

We are getting an unexpected number of POSTs to the form's action URL.

Each one has a different, and apparently genuine, email address, but we are getting way more than we would expect for our little website.

What possible malicious purpose could these POSTs have? We have never sent email to any of the addresses submitted, yet the POSTs continue.

There is nothing else in the POST request. Nothing else in the body, nothing added to the URL, no query parameters, nothing that looks like SQL injection attempts, no unique IDs to identify the request, no garbage, nothing.

The rate is less than a hundred a day. Nothing that could suggest a DOS attempt.

The source IPs are different, but the User Agent strings are always the same, which suggests the requests are coming from a bot or a script.

It all seems pretty harmless, but I'm curious what the purpose could be in abusing our form like this?

The attacker may not know that the form doesn't do anything. In particular, they may assume that it sends an email to the submitted address (which is a fairly common pattern, used for sign ups). In that case, they could either be trying to annoy people, by having lots of junk sent to them, or to increase the noise level for the email addresses spam filter - if it accepts your emails, even though the user hasn't actually submitted their address, the user may start flagging extra things as spam (resulting in them missing something important, like a password reset email), or the spam filter may start considering more things as "useful", and hence be more likely to allow actual spam through.

I'm dubious that it's a particularly effective approach, given modern spam filters, but it would be low effort.

Another possibility is that they're trying to get your system into spam filter lists. This obviously wouldn't work if you aren't actually sending anything, but it doesn't take a lot of messages to be marked as spam before sites like Gmail start filtering or flagging messages as potential spam.


Security Bugs in Scala Code I'm currently reading "Software Security: Build Security In" by Gary McGraw, and he makes the distinction between security bugs and security flaws. Security bugs being implementation errors in code, and flaws being more on the architectural/design side of software. He writes how security defects tend to be around a 50/50 split between bugs and flaws.

However, this was written in 2006, and he mentions languages such as C and C++. There is a lot of talk of buffer overflows, for instance. My question is this: how pertinent is this to Scala? Obviously bugs in implementation still can cause security risks, but having a managed language on the JVM that does bounds checking seems like it would mitigate a large class of bugs that McGraw speaks of. Is it a reasonable statement that Software Security, in a language like Scala, has shifted more towards the architectural and logical side of things? Or, to be more specific, is static code analysis in Scala less important for security than it would be for languages like C and C++? If not, why not?

As far as memory related issues go, there are still issues e.g. you can still stumble upon a null pointer, use an out of bounds collection index, accidentally share mutable data with other classes, make the application use all its allocated memory, or in some cases where almost all the memory is used and a lot of new temporary objects are created, the GC can take up almost all of the execution time - but most of these are exceptions/errors on the JVM, and can be handled, though they should be avoided with configuration and careful coding, if possible.

Additionally, in scala null is frowned upon in favour of Option, and mutable state in favour of immutable, so with an idiomatic functional style, null and mutability issues are reduced further.

There are a few scala static analysis tools (disclaimer: I'm the maintainer of Linter), but they aren't specialized for security. That said, they often find issues that would crash the application at runtime, make it run slower than necessary, or find code that logically doesn't make sense - all a potential source of security issues. I'd like to mention Wartremover which features checks that restrict the language to a more safe/pure subset.

You can also use the tools that run on the JVM bytecode, e.g. find-sec-bugs plugin for Findbugs. The default Findbugs checks work too, but are triggered by generated scala code, so there are a lot of false positives. The language authors do look at these results, and fix if they find anything, but unfortunately the false positives make Findbugs less useful to the rest of us.

(I'm very interested in hearing if anyone has used any other tools with Scala in the comments)


When I reset my password for my Microsoft account, how do they know what password I've used before? Assumption used: all password that I've used have been salted with some random elements before hashed and stored somewhere in their database.

If my previous password exists only as salted-hashes in their database,then when I:

trying to use a previous password during the password reset phase (as I type it into the new password textfield), how did they know that I was using a previously used password?

(side note: Please down vote this question if it is not really constructive or thought provoking,so I can take corresponding measures.)

They know the value to which your previous password(s) hashed, and the salts used. When you type your old password, they compare it to the old stored passwords.


To what extent does formatting a disk (securely) remove its data? If the goal is to make data no longer retrievable, how secure is it to format the disk? I assumed formatting the disk overwrites free space (thus making it a safe bet no one's going to be able to retrieve the data) but according to webopedia this is not the case. How much more secure is it to delete files with an erasure utility (using something like Schneier's method)than formatting the drive? How does formatting the drive not erase all data: formatting involves recreating the file system so this seems to imply the data is not retrievable.
I generally do not choose the "quick format" option.

Quick-formatting a hard disk simply erases the filesystem's structures and tables and writes new ones in place, giving the illusion of a brand new disk. Old data is simply overwritten as and when needed, but it still remains on the disk. File carving utilities can go through the disk data and recover fragments of files, then stitch them back together without needing the original filesystem entries. This is commonly offered in commercial "undelete" applications, but more comprehensive methods are available in forensics packages.

Wiping a disk with a single pass of random data (or zeroes, or whatever really) is sufficient to fully remove all traces of the data from the overwritten sectors. Multiple passes are pointless on modern disks, even against the perceived threat of hardware-level recovery attacks. I refer you to this question for details, but the short answer is that old techniques like magnetic force microscopy (MFM) were never really effective at recovering overwritten data in the first place on low-density devices, and newer magnetic disks have such high densities that it's physically impossible. Multi-pass overwrites are there to help people validate their need for über-security, or sell magic disk wiping software, despite it being pointless and detrimental to disk longevity.

The only exception is flash (e.g. USB flash drives and SSD), which have additional wear-leveling sectors to increase the lifespan of the device. The physical sectors are exposed as a logical map to the system, which makes it impossible to directly overwrite all of the data. Even if you overwrite all the logical sectors, old data might remain in the wear-leveling sectors. In order to combat this, some flash device specifications include an encryption requirement to increase the difficulty of recovery (because it is no longer possible to directly read data from the memory chips using hardware probes).

In SSDs, encryption can be used to speed up the ATA Secure Erase feature. All sectors on the disk are encrypted using a key stored in hardware, and this key can be discarded and a new one generated when a Secure Erase command is sent to the device, thus rendering all data on the disk (including slack / wear-leveling areas) unreadable. Secure Erase is also possible without encryption, but then the drive must actually delete all memory cells, which may take a while.


Correct terminology when describing password security to layman I am writing a page for our website which describes the measures we take to keep our customer's information secure. On this page one section describes how we keep their passwords secure.

We are using Secure Password Storage v2.0 which is an implementation of PBKDF2. We are using the hash algorithm SHA256, 64000 iterations, and 24 bytes for our random salt. I'm not really sure this matters so much, other than that I just don't want people to come with pitchforks raised thinking we are encrypting the passwords.

Is it correct to say "The passwords which we store cannot be decrypted"? I worry that it implies that the passwords can never be cracked, which simply isn't true. However, I do want to emphasize to our users that our system to store passwords is secure enough that they shouldn't ever have to worry about it (as long as they pick a sufficiently unique password of course), even in the case of the entire password database being stolen.

Other options I have considered are "The method used to store passwords cannot be reversed" or "In the case of a breach, your password should not be retrievable" but I find saying they can't be decrypted to be more understandable and to the point, especially since some people may not even realize that passwords aren't stored in plaintext.

"We believe the secrecy of your passwords is very important, which is why we have implemented measures that strongly protect them while stored on our servers.  Once you submit your password we convert it using a cryptographic function (salted PBKDF2-SHA256 with 64,000 iterations for the tech savvy), so even if attackers are able to breach our site they won't immediately learn your password.

This method of storing passwords makes it significantly harder for your password to be cracked by the bad guys.  Choosing a unique and good password/passphrase choice paired with this technology can help prevent unauthorized access to your account.  Even our employees won't know your original password."

Similar to Adam's suggestion, just expanded to cover more of your concerns.


What are the possible exploits over a debuggable APK? I have heard that an Android APK can be debugged if  android:debuggable="true" is set. What are the possible threats in allowing an app to be debugged?

Shipping application with debug means that anyone with physical access to the device can execute arbitrary code under that application's permission. If the application holds sensitive data, it will be fairly straightforward to extract that sensitive data from the application. Doing the same on nondebuggable application would require the attacker to first obtain root privilege or find an exploit in the application itself.

Shipping without debug shouldn't be considered as a protection against the user themselves though. The legitimate user of a device have all the time they need to root their own device, and so can gain any secret stored by any applications running in their device with or without debuggable application.


What steps should one take to provide "reasonable" levels of privacy from a government? I'm highly uncomfortable with the recent news surrounding government snooping in the UK.

If we define a typical user to mean somebody who:

Browses web sites such as BBC News and Stack Overflow
Uses "web applications" like Twitter and Facebook
Sends and receives email using something like Gmail or Hotmail
(more advanced) Manages some kind of small personal server

What should that user be concerned about with regards this level of government interference? And what could that user do to improve their online privacy?

In terms of first steps, I have installed the EFF's HTTPS Everywhere extension and am considering encrypting my email sent via Gmail by following a guide like this, though I'm aware this is hardly a lot. I'm looking for the "best" trade-off between convenience and security, though obviously that is subjective.

Unfortunately, HTTPS is about as good as it gets in a situation like this. Encryption will help you prevent someone from viewing your messages in transit, and HTTPS is the correct tool for that in this case. However, the real security hole here isn't transmission of data, it's who you're sending it to.

Whenever you visit BBC News or Stack Overflow, they obviously know that you visited them. You can hide who you actually are with Technologies like Tor, but having an account on a website will still allow them to keep track of you.

Twitter and Facebook, on the other hand, are going to leak information about you no matter what. In fact, that's the whole purpose of the two sites. Twitter and Facebook are frameworks communicating with others, and both of them favor making information available publicly instead of privately. Additionally, because they are bound by laws to cooperate with government agencies, even information that you ask to have stored privately can still be made "public." The moral of this story is this: if you give information to Facebook or Twitter, the government will also have access to that information regardless of how you transmit it to them. To only way to keep information private in this case is to stop using Facebook or Twitter, or at least cut back to only posting information that you are OK with anybody and everybody seeing.

In the case of managing a server, the trust is put on the company managing that server. If you have access to the hardware and software of the system, you can take some steps like Full Disk Encryption to prevent the management company from snooping on your data. Unless you can prevent the management company from physically accessing the machine while it is running, however, any data that is usually stored in RAM is not safe including Secret Keys. Again, the weak point is in the person you are sending the data to, not the method you are using to send the data.

The only real way to protect yourself in the case of a government entity snooping on you is to throw out all of your electronics and go live in the woods. Since that's not really a realistic or desirable solution, you are never going to be able to totally mitigate all the risk of your information being made available. HTTPS will probably take care of about 80% of the risk. Modern encryption is so strong that nobody except you and who you are talking to will be able to see the data being sent over an HTTPS connection. The last 20%, however, is filled with all the stuff that doesn't have an easy answer. The more you use Facebook, Twitter, GMail, etc, the more risk you will have.


Can i increase my keys tested per second using a dictionary attack compared to bruteforce...? I'm using cudahashcat to bruteforce my sky router with 8 character all uppercase password, with keys tested at around 4200k/s.
When using cudahashcat with a dictionary i created with crunch, i'm still getting the same amount of keys tested per second.
I'm asking this as i saw somewhere before stating you can test 100% more keys per second read from a wordlist, but i can no longer find this post.

Any help would be much appreciated.

Using a dictionary isn't going to increase your rate of attempted cracking, as the program still has to take the input, apply whatever hashing algorithm is required, and then compare with the password to be cracked.

The use of a dictionary is that if the password is the same as one in the dictionary (or similar if you're using mangling rules), you'll find it a lot faster.

Even large dictionaries are very small compared to attempting to guess every single possible password.


What is going on with my VPN and is it anything to worry about? When I connect my VPN to certain servers in Europe and go to ping.pe I get an address that is in the UK, even if I am connected elsewhere. I believe this might be the address of the company that hosts the servers but strangely enough with other servers (that appear to be from the same provider) I get an address in the same place as where the server I am connecting to is.

Example:

UK address: https://i.imgur.com/rIkDRJ8.png

Switzerland Address: https://i.imgur.com/x70HigV.png

Both appear to be hosted by M247 Ltd (which is based in Manchester UK I believe), one even says Zurich infrastructure and the other says Zurich dedicated servers if that makes any difference?

Can anyone:

1) Explain what is going on?

and

2) Tell me if this is of any concern in terms of privacy/security/anonymity of my VPN?

Thank you!!!!

You are looking at the wrong address.  There, at the very top of the "UK address" picture, you see that it is in fact an address in Switzerland.  The IP address is what is traceable about your connection, and the address in that picture (185.236.201.147) is listed in Zurich.

In fact, you can also look at the GEOLOC value and see coordinates in Switzerland, as well as a COUNTRY value of CH.  So the IP address you are looking at is registered in Switzerland.

Below the information on the IP address, you are seeing information about the registered assignee who controls that IP address (the IP's owner).  The owner happens to have a business mailing address in the UK, which is what you're seeing in the second section there.  Let me be very clear, the second data set on that page is not information about the IP address, it is information about the registered owner of the IP; therefore it is not required to have any details at all matching the IP's actual/physical location  (In your 2nd picture, the registered owner of the IP address is the Zurich office for GlobalAXS, hence the CH mailing address.)

So, the TLDR answer here is that you really are using a VPN hosted in CH, and you're just looking at the wrong info on that web site.

The more fun answer is that the information you see listed for the IP doesn't even necessarily have to be accurate.  Last week I had an IP address listed as from Ecuador on a cloud-hosted machine that is sitting in a Microsoft data center in West Virginia, USA.  I've heard of other people with machines in the same data center that had IP addresses that were originally assigned to India.  While these IP assignment databases are supposed to be properly updated, a large enough company that has IP addresses in several different regions and private interconnects between those regions could actually cross-publish routes and get stuff really screwy.  Microsoft was apparently running out of USA based IP addresses so they funneled some of the Ecuadorian and Indian addresses into the East USA zone; whatever, the routes all still work in both directions (it still goes into a MS Azure center).  But that just goes to prove that geo-IP lookups can be very inaccurate.

And with a VPN the service you're paying for is to protect you and your identity.  Both of these (even if it had been in the UK) do that.  In both pictures the IP addresses shown are not yours and instead map back to a GlobalAXS Network Operations Centre.  That means the VPN is working an you're secure; anyone looking will see that the client they are talking to is GlobalAXS and not IkiH.


WRT1900AC and network monitoring I just set up a new home network for my mom using a Linksys WRT1900AC router, and it has 24 devices on it right now, yet will have more soon.

I can see the network map through linksyssmartwifi.com, yet I would like a log of everything that gets on the network and I want some kind of sniffer to monitor and analyze the traffic.

This router does not have SNMP traffic or netflow sensors.

Does anyone know software for monitoring a home network that is compatible with the Linksys WRT1900AC?

You won't be able to do this with the stock firmware. You should change over to openWRT to do what you want.

Download the .iso from here. (I recently installed the Attitude Adjustment iso). Go into troubleshooting (I think) and on the right hand side it says update firmware. Just point it to the ISO and you will have a much more flexible router.

From here you have great control over logging, firewalls, interfaces etc. iptables will be installed by default and you can use that to do almost anything you need.

See the openWRT page for more.

From here you can set up port mirroring with iptables and send it to an IDS/IPS like snort or suricata. If you want to use a central logging system (to forward the logs from the IDS you might use something like ossec). Note that all of these tools come with security onion if you prefer ubuntu.


Timing Attacks in RSA Considering the classic scenario of Eve trying to listen in to Alice and Bob's conversation, if Eve can intercept messages between Alice and Bob but with no access to their computers would Timing attacks be possible? Am I right in saying it isnt possible because say Alice sends a message to Bob how will Eve listen in to how long Bob's computer will take to decrypt the message?

Eve could not just listen to the communication. If you're talking about RSA I assume that Bob's public key is not secret and that even Eve might know it. Then Eve could try to act as Alice by sending messages encrypted with Bob's public key to Bob. If Bob always answers those messages Eve could use the delay until Eve receives the message to perform a timing attack.

Even if Eve can only listen to the communication and Bob sends a reply to Alice every time he receives a message Eve could measure the time between Alice's message and Bob's reply.

Only if Bob does not reply to Alice's messages a timing attack would not be possible. If Bob must reply to Alice's messages Bob must reply only after a fixed amount of time. For example, if it takes at most 100ms to decrypt a message and Bob decrypts some message in 78ms, Bob has to wait 22ms until he is allowed to send a response.


Exploiting buffer overflow When I download a copy of a vulnerable program and try to exploit it by buffer overflow (any internal function calling as a payload), it works.
However, when I made a same type of vulnerable program in C I am not able to exploit it and I have no idea what's going wrong. Checking on gdb I figure out that I am able to overwrite the return address on the stack but still getting a segmentation fault and my desired address is not executed.

The vulnerable program:

#include<stdio.h>

input()
{
    char a[4];

    gets(a);
    puts(a);
}

main()
{
    input();
    printf("\nthis will execute after returning from the function\n");
}

over()
{
    printf("this can only be executed by the hacker");
}

I want to execute the function over() and I used the payload

printf "aaaaaaaa\xb3\x84\x04\x08" | ./my

The main problem with your code is that it isn't vulnerable to a buffer overflow more than likely due to the compiler (are you using gcc?) replacinggets withfgets

If you strace the above compiled code (with malicious input) you should see what I mean.


Protecting against planted evidence This question was motivated by this 2018 article by the Electronic Frontier Foundation that discusses the findings from the Mark Rettenmaier case.

For a bit of background on that case, this article at ocweekly.com explains

  Rettenmaier is a prominent Orange County physician and surgeon who had
  no idea that a Nov. 1, 2011, trip to a Mission Viejo Best Buy would
  jeopardize his freedom and eventually raise concerns about, at a
  minimum, FBI competency or, at worst, corruption. Unable to boot his
  HP Pavilion desktop computer, he sought the assistance of the store’s
  Geek Squad. At the time, nobody knew the company’s repair technicians
  routinely searched customers’ devices for files that could earn them
  $500 windfalls as FBI informants. This case produced that national
  revelation.

The $500 payment to the Geek Squad employee is, according to EFF, shown in this document and on page 15 of this document.

I have no issues with authorities being alerted by Geek Squad if they find something suspicious in the course of their daily work. After all it is similar to me calling the police if I see someone trying to break into my neighbors house (I would just not expect to get a bonus payment for doing so).

The concern I have here is about payments and possibly other motivating factors (such as political) that may cause a technician to plant evidence on a user machine.

Are there any strategies (from technical perspective) that could be used  to prove ones innocence against evidence planted on a customer's computer, or is that an unnecessary concern?

There’s a bunch of discussion embedded in your question.

Personally I would never trust Geek Squad, but most people don’t have a viable option.

First of all, make sure you understand that you are handing over everything currently on your machine, most things recently deleted from your drive, and many back versions of things on your drive. Do you trust this information with whomever?

Ideally you have backups, but most people don’t and that’s why they are trying to get their machine fixed in the first place. If you can backup or “image” the drive first, great, but most people can’t do that. Even if you did, who’s to say it’s a real copy of what was provided?

The most practical thing you can do is record exactly when you hand over the machine for repair by obtaining a time stamped receipt. This is the most likely basis for any future legal challenge.

While it’s technically possible to plant evidence with consistent time stamps, realistically it’s more difficult to get it right than one might think.

Legal “Chain of evidence” becomes a very powerful argument for a good attorney, and a chain that runs through “Geek Squad” is less than ideal from a prosecution point of view. That said, the detailed forensic analysis of the "Time Line” is still a potentially powerful factor for both prosecution and defense.

The unfortunate reality when it comes to criminal system forensics is that the prosecution is well funded, but the defense is mostly on their own and public defenders are not funded to hire forensic resources.


How to 'pair' a client/server application securely? Please forgive me if my question is a rephrasing of a common problem, but I am not sure what to search for!

My use-case is a client-server program. The server runs on a user's PC and the client runs on their mobile device(s). The clients need to be paired to the server in a secure way (e.g. enter a PIN or password once-off), and once the pairing is completed then we need to ensure that the client can securely verify the server, before transmitting confidential data from time to time.

Earlier in my research I thought it would be possible to use RSA keys, but this approach seemed too novel and complex to implement securely.

My current idea is to implement a scheme like this:

At initial pairing, Diffie-Hellman key exchange between client and server
Server displays a random PIN, and client enters it for verification (preventing mitm). Only a couple of wrong PIN attempts are permitted before the pairing attempt is dropped.
Since the server and client now agree on a secret key, we can simply encrypt all communication with this key. Although the server may have multiple known clients (say up to ten clients), the server could simply check any incoming connection with all ten of these keys. And since the client uses the same secret key, if the server is an impostor, decryption will not be possible.

Now my question, is this a reasonable scheme or is there a clear standard protocol that can achieve similar aims?

Reinventing the wheel is a bad idea in software development in general, but especially bad when security is concerned. Before (or instead of) designing your own authentication protocol, you should look at existing ones like TLS or Kerberos, understand how they mitigate possible attacks and perhaps even chose an existing protocol to use in your application. You will avoid many common pitfalls, save on development time and your app will have better compatibility, should you want to have it. TLS specifically seems like a good fit to your use case.

By the way, could you explain how displaying a random pin would prevent MitM attacks? Wouldn't the attacker see the very same pin as well?


How to maintain validity of user credentials? In an example scenario consider that;

I am a customer of organisation and I have two separate accounts with two different departments X and Y.
I can login in to each department's website by using user id and password that is unique for each department.
To update my personal details in any deprtment, I have to call this service provider and use a PIN code (sent to me earlier, through a secure channel). They have separate teams for each department so X doesn't know about Y.
Although I have separate profiles/accounts for each department, note that the PIN code is the same whether I call department X or Y.
In this scenario both departments have different levels of allowed actions associated with PIN code. For example I am not allowed to change my address when calling department X with this PIN because its considered lower level authentication factor. However if I want to do the same in department Y, I may be allowed to so because it is considered as higher level authentication factor.

Now the problems I see in this scheme are:

A fraudster who has somehow skimmed my basic details, like Name, DOB etc can call department X ask for this PIN (which ironically can be given over the phone) because its considered to allow only low risk operations. Consequently once the fraudster gets this PIN, he can then call into department Y and perform changes without being challenged because its allows high risk operations.
Second problem is that same PIN number is used for two different departments.

Now my question is that consider I can't have separate PIN codes's and they can't have same level of authentication associated to them for X and Y.

What can the organization do to stop fraudulent  use of PIN  code across different departments
Is there a way to maintain the validity of credentials by associating change of scope (department which resets/re-issues PIN code) and extent (change of personal information) to PIN code. So that misuse can be stopped.

This organisation should have a specific landing point for customers to receive/verify/modify their PIN code, which does not depend on departments, and department staff should be trained to not give this information just as they would not give other sensitive personal information.

The reason is you can't ask departments to reason about the sensitivity of the PIN code themselves if they don't know what others are doing (or will be doing in the future) with this PIN. Also, it'd be much costlier to setup an organisational or technological mechanism for departments to check the sensitivity of the PIN in situ so they can decide whether to disclose it over the phone or not. It's easier to have a separate team for handling the PIN so a unique policy can be created, updated and enforced.

Note that at this point it makes a lot of sense to have a cross-department account management system with some amount of information reuse. You already need this for such a PIN (though I must say the primary issue probably is that the PIN exists in the first place).


search for exploits in metasploit I scanned my network using nessus and imported the .nessus file to msfdb. Then I executed the vulns command to find vulnerabilities in the imported nessus scan. Is there a command that identifies which vulnerabilities are exploitable?

You won't know which are exploitable until you successfully exploit them.

By definition, the vulnerabilities identified are likely to be exploitable, otherwise they would not be identified as vulnerable.


Router Security Log Shows Many Blocked TCP Connections When checking my router tonight I looked at its security log. I saw thousands of blocked tcp traffic. Why are these considered security events? The log shows many blocked tcp incoming request from many different ips and on different ports. Here is one example below:

Does a log fill up with thousands of blocked tcp events like this through normal internet surfing or is this something to be more concerned about? Or does this just mean the router's firewall is just doing its job and logs every time it receives tcp traffic inbound that I did not initiate?

(As a side note I did find UPnP was on and Wifi Protected Setup was on too by default, so I turned those off)

You don't have to worry about this logs. Anything connected to the internet will receive lots and lots of connection attempts every day, from random scans, bots, and security researchers.

Just configure the router to deny WAN access and you will be protected from the vast majority of the attacks. And your router will generally rotate the logs when they grow past a defined threshold, so its storage will not fill up with logs.


Best way to allow sudo access when using ssh keys Probably a simple question, but I can't seem to find any actual best practices out there. I manage a handful of servers and I am really getting sick of tracking my passwords in pwsafe. I've been considering implementing using SSH keys for authentication, rather than passwords but I have concerns about the best way to implement sudo rights to users in that case.

I know a lot of people modify /etc/sudoers to have and set their needed users to NOPASSWD. But I see no mention of people giving their users passwords, so I have a hard time doing that. What if my box is owned as a non-privileged user, all it would take is a quick 'su user' into my NOPASSWD'd user and I'd be done for, in theory. Or worse yet, physical access and someone who knows my username.

Is it best practice to go ahead and set a password on those accounts, or are there some other mechanisms used such as preventing local logins or do people just set a password and throw it away/never use it?

The NOPASSWD option allows the sudo program to be executed by the sudo user without having to enter a password. It does not imply that your account is password-less.

Other users that run su youruser still need to enter the password for youruser. But if you are logged in as youruser (via physical access or over SSH), then you do not have to enter a password when you run sudo somecommand.


Best Practice Storing Sensitive Information in Web Application I am developing an application in php/MySql and looking for the best approach from a security standpoint.  The application will use and store sensitive information.  I realize there are risks to all approaches, but I need the best possible approach that will minimize security risks of the sensitive information with this application.

Here is the foundation of the application:

1)  Entire application runs with https and php 7.

2)  User registers for an account at register.php and passwords is hashed  password_hash and Password_BCRYPT during registration.

3)  User logs into the web application via login.php

4)  Once logged in, user visits manage credentials page (manage-accounts.php) and on a web from enters url, user name and password for third-party websites (basically like a password manager).

5)  Next user visits manage-customer.php page and enters sensitive customer information that includes ssn#.

6)   Lastly user visits submit-customer.php page.

On this page the user selects one of the third-party websites entered
in step 4 and a customer entered in step 5 and hits submit.
Upon submitting the php script, it will iframe the selected
third-party website (third-party website uses https).
It will automatically log the user into the third-party website
(with credentials from step 4).
It will autofill sensitive customer information to the third-party https web form (with customer information from step 5).
iii.    It will submit the third-party webform.

Here are my questions:

1)  For a system like this, what encryption/security methodology is
   considered best practice to maximize security of the sensitive
   information that is stored in step 4 and 5?

I am not looking to create my own encryption.  I’d  like to use an
existing proven framework.

2)  What is most secure way to transmit the information from step 4
   and 5 to a third-party website via the iframed web form?

3)  Is it better to store the sensitive information entered in step 4
   and 5 on the server or on the client?  If on the client exactly how
   should this be done?

The full scope of this question is huge (several aspects of secure application design). I'm not sure a simple Q&A here will suffice.

Given the seriousness of what you're attempting, you should get a strong AppSec pro into your team and consider a holistic approach that includes that includes threat modeling, secure design, secure coding principles, security testing and verification.

I'll attempt short answers for pointed questions - with the disclaimer that AppSec pundits are still debating some of these, especially as some of the answers are "evolving" (e.g., secure credential storage - some discussions around favoring K12 and Blake2 over PBKDF2/ bcyrpt / scrypt).

This was not a question but:

  2) User registers for an account at register.php and passwords is
  hashed password_hash and Password_BCRYPT during registration.

Please make sure you're using a sizeable random salt. See this old discussion on hash and salt size for some understanding.
OWASP has a decent and recent guide for this here. Note that the 2013 discussions were about 64 and 128 bit salt. OWASP mentions 64 byte (not bits) salt. Also recommended are keyed functions - not just simple hashing.

Finally, you mentioned "basically like a password manager." That complicates matters a bit. You will want to leave the user in control - with at least a reasonable assurance that part of the keys to the kingdom are locked away in their brain or their system. The usual method for this is that the user's master key (password) is not stored anywhere (not even on the local system) but is used to derive the key(s) used for password storage.

Now for your questions:

  1) For a system like this, what encryption/security methodology is
  considered best practice to maximize security of the sensitive
  information that is stored in step 4 and 5?

Sorry, no short answer for this question.

This system would need a comprehensive threat modeling + a privacy as well as security design from ground-up. It is good that you started off quite well - but please don't underestimate the tasks at hand. OWASP has guides for most parts, though people with deep expertise have been known to diss some areas (usually on the count that "it's not perfect" ... which, I consider a pedantic objection).

  2) What is most secure way to transmit the information from step 4 and
  5 to a third-party website via the iframed web form?

As a security-conscious user I don't trust iframes. I don't recommend them to users. If what you're doing is akin to a password manager functionality - I suggest you explore alternatives.

  3) Is it better to store the sensitive information entered in step 4
  and 5 on the server or on the client? If on the client exactly how
  should this be done?

Please see a previous para where I mentioned master key (password).

If you follow that advice, then you should store the per-user hashed-stash of passwords on your server. There is no real (technical) advantage of storing properly hashed/encrypted passwords on the user's system where it can easily be wiped out for a number of reasons.

Hope this helps.


AWS - CloudFormation - Enable MFA Is there a way of using cloud formation to enforce MFA on user accounts in AWS:

I have the following cloud-formation code:

{
    "AWSTemplateFormatVersion": "2010-09-09"

    "Description": "Security Cloud Formation Template",

{
  "Resources": {
      "Type": "AWS::IAM::Policy",
      "Properties": {
      "Users" : [*],
      "Action"   : [

      ]
      }
  }
}

I'm not able to find an action (in the AWS list) or able to work out a way of enforcing MFA on an account.

Yep, you can do this.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "AllowUsersToCreateEnableResyncDeleteTheirOwnVirtualMFADevice",
      "Effect": "Allow",
      "Action": [
        "iam:CreateVirtualMFADevice",
        "iam:EnableMFADevice",
        "iam:ResyncMFADevice",
        "iam:DeleteVirtualMFADevice"
      ],
      "Resource": [
        "arn:aws:iam::account-id-without-hyphens:mfa/${aws:username}",
        "arn:aws:iam::account-id-without-hyphens:user/${aws:username}"
      ]
    },
    {
      "Sid": "AllowUsersToDeactivateTheirOwnVirtualMFADevice",
      "Effect": "Allow",
      "Action": [
        "iam:DeactivateMFADevice"
      ],
      "Resource": [
        "arn:aws:iam::account-id-without-hyphens:mfa/${aws:username}",
        "arn:aws:iam::account-id-without-hyphens:user/${aws:username}"
      ],
      "Condition": {
        "Bool": {
          "aws:MultiFactorAuthPresent": true
        }
      }
    },
    {
      "Sid": "AllowUsersToListMFADevicesandUsersForConsole",
      "Effect": "Allow",
      "Action": [
        "iam:ListMFADevices",
        "iam:ListVirtualMFADevices",
        "iam:ListUsers"
      ],
      "Resource": "*"
    }
  ]
}

http://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_delegate-permissions_examples.html#creds-policies-mfa-console


LFI to RCE through User-Agent I'm doing a pentest on a FreeBSD machine running CuppaCMS. Already managed to login into the CMS with admin privilege, but it only takes me to a manager menu, with some options to change some tables and stuff like that, no RCE visible escalation. So i discovered an exploit on exploit-db.com that leads to LFI, after some research i was able to do RCE through User-Agent and GET requests sending . So i'm able to read the directories and "cat" some of the files out while reading the httpd-access.log file, but i can't run any reverse shell on the server, seems like i can't even 'nc' to my machine. I managed to send a php code through the User-Agent doing the reverse shell but when i did it, the server simply crashed. Any ideas on how i could continue to explore the machine?
Thanks
Update-1:
Sorry, i was a bit tired when i first posted it.
So, i'll put here what i got till now.

Whoami = www

I can read apache logs & conf files, passwd, groups.

There's two users with /bin/bash in this machine. (Root and gerencia)

SSH is enabled. I tried to brute-force it with rockyou.txt as the pass_file for gerencia, but didn't work out.

Reverse shells used(pentest monkey): bash, php, python.(none of them worked)

I searched for id_rsa files in the home directories, found none.

When i list the /home directory it show nothing, but when i list /home/gerencia it works.

Found something a bit different, some /home directories are in /usr/local instead of the / dir.(/gerencia and /gerente)

I can't 'echo' into files, doesn't matter if i'm in a rwx dir.(but i can 'touch' new files)

Wget doesn't seem to work.

Found out that ossec is running on the machine.

Tried to echo a reverse-shell into sh script, didn't work as well.

I first started to study pentesting this year, still learning, sorry. Hahaha

You may want to update the question and show us the reverse shell that you are trying. Also, if you are able to read file, have you tried reading /etc/passwd? Is SSH port open? how about /home/someuser/.ssh/id_rsa? If you get lucky then you can possibly SSH into the server using this user private key? You can read webroot dir config file where users normally have database connection credentials. Try login with it to SSH, FTP, CMS, etc. There are numerous things you can do


Storing password hashes without a correlation to the user account I read an interesting article about an alternative way to store password hashes ans was rather intrigued.

A better way to store password hashes?

The primary concept is having a large table full of salted password hashes that doesn't have any key tying them to a user; the user records would contain only the unique salt. When a user attempts authentication, the provided password is then hashed with their salt, and if it exists, they are authenticated.

This allows for a huge amount of fake data, making the hash table practically useless to an attacker, not to mention far to large to copy/transport easily (eg, via USB key).

Is this a sound method?

What kinds of metrics can we use to compare this with the more common method of storing a hash in the user record? Any Experts care to give us a comparison?

Maybe I don't understand but if I were an attacker I would do the following:

I would steal both tables.
Then I would select a user I am interested in (e.g. an administrator) and start hashing passwords using his salt and look if the resulting hash is to be found in the hash table.

So what's the difference? (except that I have to lookup if the computed hash exists instead of just comparing (DB servers are good at such tasks)

P.S.: The author also argues that the size of the table might make it harder for the attacker to steal it. That's a good point. (Unless he doesn't steal it but runs the lookup queries on the site's DB servers)

It is an interesting idea that should be topic of more (academic) research.

P.P.S.: The author suggests a method to fix the hidden backdoor problem here. On first impression this seems to fix it.


Is loopback interface protected from sniffing? I'm trying to understand what are the risks derived from unprotected communications within the same device, by the use of the loopback interface. I've verified it is possible to capture packets, with administrative privileges, on both Linux and Windows systems, by using Wireshark or RawCap/SocketSniffer tools. Would it be possible for some kind of malware to capture packets exchanges on the loopback interface in the same fashion, provided the malware obtains the needed privileges ?

If you can do it (with Wireshark or another tool), then any program that has the same privilege level as you can theoretically do it as well.

So if the question is: can the loopback interface be sniffed? I'd reply YES. From what I know, it's more or less the reason why it was created in the first place.


how to create an encrypted ssh tunnel between local machine and final machine? My machine at work is behind a firewall. To connect to it first i need to connect (ssh) on another machine and then through this machine i make the ssh on my machine. In other words, there is a middle machine between my local computer and the final remote computer. How can i create an encrypted tunnel between my local computer and my computer at work?

Note: Using OpenSSH

In reading your question I have to assume “my local machine” is outside the company network, like in your home or somewhere on the Internet.  More well defined locations, operating systems in use and a brief description of your company environment would assist those attempting to answer questions.  For the purpose of this response I'm going to give systems identified in your question some names.

“my work machine” = work-machine
"my local machine” = home-machine
“another machine” = jumpbox

This is really a matter of company security policy.  Connections from the Internet to systems on a company's internal network are typically not allowed because they provide a path for attackers to access internal resources and ex-filtrate data.  I can only assume that the jumpbox you are connecting to is a gateway device (preferably in a DMZ) that exists for some combination of authentication, authorization and accounting, and potentially inspection.

That being said, if policy permits, you would need to have your firewall administrator permit connections from your home-machine to your work-machine.  This is typically undesirable if you're coming from a dynamic IP address that will change over time, as the firewall administrator will need to allow broad ranges of IP addresses in to the network.  Ideally, if inbound connections are permitted to your company network you will always come from the same IP address when connecting from your home-machine.

Alternatively, you could use a reverse tunnel using SSH; again, if your company policy allows outbound SSH connections.  The -R option in SSH allows you to build reverse tunnels.  For this you would require a method of connecting form your work-machine to your home-machine.  You'll need to consider following items:
    1.  Name resolution (if your IP changes at your house): There are plenty of dynamic DNS providers out there.
    2.  Port forwarding if you're behind a NAT device, such as  a DSL router.
    3.  Your home-machine or another dedicated system would have to be running SSH server to accept the ssh sessions coming from your work-machine.

Once you've configured services required in 1-3 above, you can make a connection from your work-machine to the SSH server running at your house.  From your work-machine, the command might look like this:

ssh -R 192.168.12.202:5556:127.0.0.1:22 ricardo@my.house.com:4444

If I were to speak the command above, it would go like this:  Use ssh to create a reverse tunnel (-R), opening a listing port (5556) on my ssh server (192.168.12.202). As clients connect to port 5556, forward them to port 22 on my ssh server (127.0.0.1), which is subsequently forwarded back to the machine originating the tunnel (work-machine).

There are a lot of technical tutorials out there which provide instructions for building reverse tunnels with SSH.


WarGames–platforms to practice and improve hacking skills Do you know of any good free platform in which we can practice different attack vectors and vulnerabilities such as XSS, SQL injection, low-level hacking, reverse engineering, etc.?

For example, I liked Smash The Stack back then. (Note: it's not recommended to get into the Tags section, Just SSH to the server and start to play).

Depending on what you call "online", a simple Google search on "damn vulnerable" will reveal the existence of freely downloadable applications of even full OS, meant for, indeed, learning all the ways software can be horribly vulnerable. One of them is Damn Vulnerable Web App, which is, you guessed it, a damn vulnerable Web app. There also used to be a full OS called Damn Vulnerable Linux; it is apparently discontinued (though of course lack of security patches was the point of it) but this question discusses replacements.

These are not "online machines" for you to hack, but you can download them and install them on a virtual machine on your own computer, which can be done for free (there are good free VM solutions, e.g. VirtualBox) and is a lot more flexible than an online target; it will teach you more since you can modify it and reset it at will.

All these resources are subject to obsolescence, modification and replacement, so the important point of this answer is to give the correct keywords for searching. And these keywords are "damn vulnerable".


ECDH BouncyCastle KeyAgreement length I am attempting to obtain a shared secret using BouncyCastle's ECDH methods in C#,
however I am receiving a shared key which is much shorter than the 48 bytes I expect it to be.

I have a trusted external source providing me (Side A) with a public key and a private key, these were generated for P192, and are of length 48 for the public and 24 for the private.

Also, I'm receiving a public key for the B side to calculate the agreement with.

I am expecting the shared key to be of length 48, but ending up with length 24.

    string P192publicA = ""; // 48 length key
    string P192privateA = ""; // 24 length key
    string P192publicB = ""; // 48 length key

    DerObjectIdentifier p192Der = Org.BouncyCastle.Asn1.Sec.SecObjectIdentifiers.SecP192r1;
    ECKeyGenerationParameters ecparams = new ECKeyGenerationParameters(p192Der, new SecureRandom());
    ECCurve curveP192 = ecparams.DomainParameters.Curve;

    ECPrivateKeyParameters ecPrivateA = new ECPrivateKeyParameters("ECDSA", new BigInteger(P192privateA, 16), p192Der);
    ECPublicKeyParameters ecPublicA = new ECPublicKeyParameters("ECDSA", curveP192.DecodePoint(Hex.Decode("04" + P192publicA)), p192Der);
    ECPublicKeyParameters ecPublicB = new ECPublicKeyParameters("ECDSA", curveP192.DecodePoint(Hex.Decode("04" + P192publicB)), p192Der);

    IBasicAgreement aKeyAgreeBasic = AgreementUtilities.GetBasicAgreement("ECDHC");
    aKeyAgreeBasic.Init(ecPrivateA);

    BigInteger k = aKeyAgreeBasic.CalculateAgreement(ecPublicB);

My result in hex is only length 24 while I expected 48.

It there something wrong with my understanding of the key agreement mechanism?
I wasn't sure about the decoding of a point, I saw in the bouncy examples they add "04" before decoding a point, and every other prefix I tried threw an exception.

Any tips will be greatly appreciated !

An elliptic curve is a point in a bi-dimensional space, hence it has two coordinates (usually called X and Y) which are values in some field. In the case of P-192, the field consists in integers modulo a prime p of length 192 bits (p lies between 2191 and 2192). The curve points are the (X,Y) pairs that fulfil the curve equation (Y2 = X3 + aX + b for two constants a and b that define the curve). It so happens that the number of points on the curve (the curve "order") is an integer n whose value is also close to (but somewhat lower than) 2192. The specific curve (the constants a and b) were chosen so that n is prime.

A private DH key is an integer modulo n. Thus, it can always be encoded as 192 bits (24 bytes) since n itself is a 192-bit integer.

A public DH key is a point; it is what the two parties send to each other. For private key u, the corresponding public key is the point uG (multiplication of a conventional curve point G, which is part of the curve definition).

When two parties U and V do an ECDH, they use (or generate randomly) their private keys u and v, and send to each other the corresponding public key uG and vG. The resulting shared secret is then the point uvG that they can both compute (but that eavesdroppers cannot compute, which is the point of ECDH).

It so happens that ECDH is defined by the ANSI X9.63 standard and that standard says that the actual shared secret is not the complete point uvG, but only the X coordinate of the point uvG. That coordinate is an element of the field in which we are working, i.e. an integer modulo p. Thus, it can be encoded over 192 bits, which is why you get only 24 bytes. Note that the value is an integer modulo p (the field modulus), while private keys are modulo n (the curve order); p and n are distinct (but both are 192-bit values in the P-192 curve).

You may ask how comes that ECDH is defined that way. The reason is mostly that point coordinates are redundant: since a point (X,Y) must fulfil the curve equation, from X alone you can compute X3 + aX + b = Y2, thus get the square of the Y coordinate. In a field, a given value can have at most two square roots, so if you have the X coordinate then you can recover Y and -Y, i.e. almost the full point. In that sense, with the X coordinate only, you almost have all the secrecy that you can expect from ECDH.

(This implies that ECDH is still possible when the two parties send to each other only the X coordinates of their respective public keys uG and vG, provided that they both recompute the missing Y. Not all implementations support that, though, since it involves some extra code for square roots, and there is some uncertainty about possible patents on the subject. In all generality, this is called point compression.)


Sudo "/usr/sbin/halt", "/usr/sbin/reboot", "/usr/sbin/poweroff" - how to leverage it to privilege escalation? A normal user can execute these commands as root without providing any password (sudo includes the full path of the command so path hijack isn't the case here), could "halt", "reboot", or "poweroff" be leveraged to escalate the users' privileges to root?

The ability to invoke as root is not a property of the names halt, reboot, or poweroff, but of the files that are executed. The setuid bit is a file permission bit that means whenever you try to execute the given file, it is run with the permissions of whoever owns it (in the case of su, sudo, halt, reboot, and poweroff, root). You cannot use mucking about with $PATH to, say, make halt point to your own executable that gets invoked as root—if you hope to abuse setuid for privilege escalation, you must find a bug in an already-extant setuid program on the system (which is precisely why setuid program bugs are considered utterly critical).
EDIT: Seeing a comment on the question has made me reevaluate what the question means, and realise the following may be better suited as an answer:
If you've configured /etc/sudoers to allow normal users invocation of an absolute path only (as you have in fact done), then whether or not users can muck with the $PATH that sudo calls on (according to the manpage, changes to $PATH pass through sudo to the executed command unless the security policy resets it, although the default security policy does), they cannot invoke arbitrary binaries named halt, reboot, or poweroff, since you specified a unique path. Once again, only if those binaries themselves can be exploited, can someone cause trouble—but the attack surface is much bigger if you're allowing the execution of a binary that wasn't originally made to be setuid. You should make sure your /etc/sudoers security policy resets environment variables, to limit the range of attack (and prevent, e.g., abuse of a sudo'd shell script which uses the $PATH)—by default it does if you haven't tampered with the env_reset flag. You can double-check by setting some environment variables, including $PATH, and doing sudo env to print all the environment variables a program run by sudo gets.


Need an overview of web service / web site security world, where do I start? Possible Duplicate:
  Resources to learn about security

I'd like to get a good understanding of modern issues in web security and get insight into what it takes to keep your sites and services secure. I'm thinking of concepts like SSL, certificates, threat modeling, authorization/authentication and many many others. I'd also like to understand it both from the point of view of the person implementing the software (I'm a software engineer myself) and the person maintaining it after deployment.

I will most likely not need to go extremely deep technically into the individual issues, but breadth is certainly important as far as anything on the web is concerned.

I know that every area of software has its core texts and resources, and I was hoping that you security professionals would be generous enough to share your domain specific resources with me so I can ramp up and gain a good understanding of the field!

OWASP, the Open Web Application Security project, maintains a top 10 list of vulnerabilities.  It's available in PDF form.

That can be a good starting point for understanding, at a high level.  "The OWASP Guide to Building Secure Web Applications and Web Services" explains how web applications can be exploited and how they can be designed for robustness.


Is there a benefit to setting up a security key on an account that already has phone-based 2FA? I'm looking at 2FA options for my Google account, and I noticed they now allow you to add a security key to your account. I'm a bit of a novice to infosec, but I'm struggling to see the benefit for me. My phone already covers the "something you have" component of account security.

The only thought I have is that a phisher could ask me to enter my 2FA code and use that to log in, and I might not notice. But I see no reason why a phisher couldn't ask me to tap the button on my security key, too.

Are there additional benefits to the security key that I'm not seeing?

I'm assuming the security key you're referring to is a U2F security key.

U2F has several advantages over other 2FA schemes like OTP, one of the biggest improvements is to prevent the issue you point out. With most 2FA schemes a phisher could simply act as a proxy between you and the legitimate service, and obtain your password and 2FA code that way. U2F prevents this with the help of the browser.

Authentication works as follows: (somewhat simplified)

The website sends a signature request
The browser validates that the AppID in the signature request
matches the visited domain (or that the domain is a trusted
facet)
The browser forwards the signature request to the U2F device
The device uses the AppID and key handle to retrieve the private key, which it uses to sign the challenge
The signature gets sent back to the browser, and on to the website to verify it

If a MitM simply acts as a simple proxy this will fail at step 2, as the domain won't match the AppID in the signature request. If the MitM filters the signature request and modifies the AppID to match the phishing domain, it will fail at step 4, as the AppID and key handle no longer specify a valid key.

Of course, the phisher already has your password at this point so you would need to change it, but at least they can't get into your account.