Google Chrome, the best bet for online privacy? You may think I'm crazy, that's why I'm here to ask. I read this page which went over the privacy and security of many if not all browsers.
From his reporting, and my own logic, that the government likely has advanced enough tracking tech that no-browser on the market can escape the honeypot/tracking, I reason that using google chrome may be the safest avenue: Why? Because the larger the crowed, the less attention each user is given, and thus the greater privacy you get.
Should I make the switch back to chrome from Brave?

Your arguments seems to be based on the assumption that the majority of tracking is done based on the browser type - which it is not. It is instead based on simple things like cookies, Etag etc but also on more complex things like Javascript based fingerprinting. Such fingerprints do not only depend on the type of browser used, but also on capabilities of the hardware and OS where the browser is running on. Thus the idea of being "part of a larger croud" using the same browser type does not really hold since there are enough ways to be more granular than just based on browser type. And how granular this can be actually depends on the browser, some (like Brave) explicitly try to limit the tracking.

... that the government likely has advanced enough tracking

The majority of tracking is not done by governments anyway. It is done by private companies trying to create user profiles and monetizing these with targeted ads. In countries where the government really wants to track individual users they can count on the cooperation of ISP in order to map individual IP addresses to specific house holds. And within a house hold there are only a few users and browser sessions which are much easier to distinguish from each other.


Is this a security flaw in LinkedIn or a known behaviour LinkedIn owns a sub-site called LinkedIn Learning.

On September 9th, I took a LinkedIn skill assessment on one course.

As I have passed, LinkedIn offered me few courses, which you can see in the above image for free for only 24 hours

Here is where I saw a strange behavior. I went to LinkedIn Learning and browsed for other courses and I saw there are no options to view the course for free for 24 hours. i.e Only the course suggested by them can be viewed free for 24 hours.

I monitored the traffic to find how suggested courses get unlocked for free for 24 hours and not other courses. After spending some time in monitoring the traffic I saw a request like this:

https://www.linkedin.com/feed/update/urn:li:lyndaCourse:/?updateEntityUrn=urn%3Ali%3Afs_feedUpdate%3A(V2%26VOYAGER_SINGLE_UPDATE%2Curn%3Ali%3AlyndaCourse%3A379656)

I saw a strange parameter in the url like this: lyndaCourse:<COURSE_ID>

So, I thought, why not replace the course id of the free for viewing course with the course id of the locked course?

Fortunately, I was able to get the course id of the locked course by viewing the page source of the code with the parameter name

When a GET request is made after the replacing unlocked course id with the locked course, it gets unlocked for 24 hours.

My first thought was it would be an Indirect Object Reference Vulnerability because there are no options to unlock the paid course for free.

Now again **another strange behavior exhibited when analyzing the HTML source **

All the videos where actually meida, i.e just embed with video tags which allowed right click download of the videos.

I directly reported to them with screenshots and proof of concept videos, and I got this response.

So I thought they took this issue lightly and posted it on LinkedIn post and tagged them.

You can see that I have demonstrated with proof of concept video again in the post.

Here is the link to the post which have also tweeted and tagged them as per the advice of other security researchers to let them know.

https://www.linkedin.com/posts/visweswaran-nagasivam-975a8b167_kirstybonner-bug-jobs-activity-6577243206126268416-6L-X

I again mailed them with the link of the post and got this response.

For a moment I thought it is not a bug and a known feature but other security researchers are telling it is a bug. To prove my point I also wrote an automated program which exploits this bug and downloads all paid courses for free which is required for a month in bulk. And still they are claiming it is not a bug.

So my question is is this a bug or some known feature or expected behaviour?

If every course can be downloaded for free, what is the need for paying?

You and LinkedIn are talking about two different things.

You found a way to use an unlock function in their code to unlock any course you want
LinkedIn knows and is willing to take the risk

You want them to take the "bug" seriously. They want to take the risks seriously.

Is this a "bug"? No, a bug is an undesired or unintended function of the system. They know about this function's effects and have told you that they accept it and have means to limit their risks that you do not know about.

There is nothing wrong with this response.

Is this a "feature or expected behaviour"? No, it's an effect of their design choices. It does not (necessarily) provide them or their users a benefit and it might not have been designed to have this effect. It's a consequence of their design.

System effects can have negative impacts, positive impacts, or neutral impacts. For LinkedIn, they see this behaviour of the system as a neutral impact.

You are seeing that something bad could happen. They are seeing that the bad is tolerable and not worth the re-engineering of their system to change it.


How do I delete secret subkeys correctly? I tried to use gpg --delete-secret-keys to delete some revoked subkeys but ended up accidentally deleting my primary key instead.

I was able to reproduce my mistake with the following commands:

$ gpg --batch --passphrase '' --quick-generate-key 'test key' rsa4096 cert 0
gpg: key 0xA52099E0E7EB77A5 marked as ultimately trusted
gpg: revocation certificate stored as '~/.gnupg/openpgp-revocs.d/D7D79C32883EA862C586881DA52099E0E7EB77A5.rev'
$ gpg --batch --passphrase '' --quick-add-key D7D79C32883EA862C586881DA52099E0E7EB77A5 rsa4096 sign 0
$ gpg --list-keys
pub   rsa4096/0xA52099E0E7EB77A5 2019-04-10 [C]
      Key fingerprint = D7D7 9C32 883E A862 C586  881D A520 99E0 E7EB 77A5
uid                   [ultimate] test key
sub   rsa4096/0x20AA2F4F7A28CD01 2019-04-10 [S]
      Key fingerprint = 9CAE 802D A78E 4624 BD8F  88FE 20AA 2F4F 7A28 CD01
$ gpg --delete-secret-keys 9CAE802DA78E4624BD8F88FE20AA2F4F7A28CD01

sec  rsa4096/0xA52099E0E7EB77A5 2019-04-10 test key

Delete this key from the keyring? (y/N)

Even though I specified the subkey by fingerprint, gpg asks me to confirm the deletion of the primary key.

The manual states:

  --delete-secret-keys name

  Remove key from the secret keyring.
  In batch mode the key must be specified by fingerprint.
  The option --yes can be used to advice gpg-agent not to request a confirmation.
  This extra pre-caution is done because gpg can’t be sure that the secret key
  (as controlled by gpg-agent) is only used for the given OpenPGP public key.

I tried using batch mode as well:

$ gpg --batch --yes --delete-secret-keys 9CAE802DA78E4624BD8F88FE20AA2F4F7A28CD01
$ gpg --list-secret-keys
# Empty output.
# Primary key has been deleted.

I specified the subkey by fingerprint but gpg interpreted the command as if I had specified my primary key instead.

What is the correct way to do this? Did I understand it wrong?

As explained by Peter Lebbing and Daniel Kahn Gillmor on the mailing list, the answer for gpg 2.2.15 is to ask gpg-agent to delete the secret subkey.

# Obtain the keygrip of the subkey you want to delete.
$ gpg --with-keygrip --list-secret-keys "$YOUR_FINGERRINT"

# Ask gpg-agent to delete the key for you.
# There should be a graphical confirmation prompt.
$ gpg-connect-agent "delete_key $KEYGRIP" /bye

gpg-agent is the program that actually manages the secret keys.
Each secret key corresponds to a file named "$GNUPGHOME"/private-keys-v1.d/"$KEYGRIP".key.
In order to delete a secret subkey, the user must obtain its keygrip and then ask gpg-agent to delete it.

Documentation for the delete_key command:

$ gpg-connect-agent 'help delete_key' /bye
# DELETE_KEY [--force|--stub-only] <hexstring_with_keygrip>
#
# Delete a secret key from the key store.  If --force is used
# and a loopback pinentry is allowed, the agent will not ask
# the user for confirmation.  If --stub-only is used the key will
# only be deleted if it is a reference to a token.
OK

Apparently, there is no way to tell gpg to ask gpg-agent to delete a secret subkey on the user's behalf.
An issue has been opened about this.


Is reverse DNS a must have to prevent emails delivered as spam? I was considering setting up my own mail server and one of the things I've read about is that I must setup reverse DNS to do not get caught by a spam filter.

Is that really a must? Aren't SPF and DKIM enough to prevent be labeled as spam?

Your question,

  "Is having a PTR record a must for sending mail servers?"

is not that easy to answer fully.

  Is it an requirement to be able to send mail?

No, you can send mail from any address.

  "Can SPF and DKIM can replace a PTR record?"

the answer is no, each of these have a different function.

and when we combine the question and look at the full problem, we have to consider that as mail senders we have to invoke trust into ourselves as a trusted party that plays nice, does not send spam etc. (e.a. we are a good sender)

In order to invoke that trust we should implement a PTR record for our mail server, a SPF record and DKIM record to protect our messages and canonical source of messages.

In conclusion, is a PTR really needed when you host your own sending mail server? Yes, because we want others to trust us as a proper mail sender.


Why does SSLStrip fail when user types HTTPS? During an HTTPS connection between a browser and server -- Is the very first packet from the browser encrypted? My guess is that the answer is "NO" because encryption should only begin after the client and server have negotiated encryption parameters.

Now, if my answer of "NO" is correct, how come the SSLStrip attack fails to work when the user explicitly types HTTPS in the address bar? Since the first  packet is unencrypted regardless of whether the attacker types https:// or http://, the attacker should still be able to hijack the connection and fool both the sender and attacker in the same way for both cases. This would mean SSLStrip should work in either case.

SSLstrip works by replacing HTTPS links in web pages returned by the server with HTTP links. This happens during a standard HTTP request, response exchange.

While the initial HTTPS call isn't encrypted, it is part of the TLS handshake and is definitely not standard HTTP requests. The TLS handshake can only result in a TLS connection or a connection failure. There's no way for it to magically become standard HTTP.

So there's no way for SSLstrip to downgrade an HTTPS request.


Legality of writing exploits for educational purposes (USA, Canada) Is it legal for me to write a small exploit (possibly to a closed issue) and put it up on the internet for everyone to see (as a tutorial)? I have been researching the legality of exploiting vulnerabilities and I came across CFAA (Computer Fraud and Abuse Act.) Looks like there is nothing in CFAA that explicitly prevents something like this but I might be overlooking something.

FYI: I am currently located in Canada and I am interested in legal issues that relate to North America.

I don't know about the CFAA specifically, but good general guidelines for educational, or exploratory penetration testing are:

Only attack servers that you control, or that you have express permission to attack. For example, some people leave up websites with known vulnerabilities so that others can "practice hacking" on them. These sites usually have a disclaimer expressly giving you permission to attack them. Without that disclaimer, you can get in big trouble for launching an attack on a domain that you don't control.
Only publish exploits for known (and patched) vulnerabilities. If you are playing with exploits that have already been published in academic journals / conferences, or are otherwise well known, then you're probably ok to post it on the internet, especially if a patch is available. However if you discover a new exploit, or are unsure if it's new, then it's better to go through official channels and notify the vendors before making anything public.

EDIT:
The OWASP  WebGoat Project exists specifically to address issue (1.) :

WebGoat is a deliberately insecure web application maintained by OWASP designed to teach web application security lessons.

You can download and install the WebGoat packages onto your own machine and then run all the attacks you want!
If you have strong concerns about issue (2.) and publishing, you could always get in touch with your local OWASP Chapter and ask them.


Is it better to use a root password, or use 'sudo bash'? When I am doing a lot of sudo operations, I like to spawn a bash shell from sudo to make the operations go quicker. I am against assigning a root password because I do not like the root account enabled because it is an easy target for hackers.

There are a couple of security concerns I have with using sudo bash as well, but to me it seems safer than just enabling the root user all together.

Which option is safer? Using sudo bash to obtain a root level shell as a nomal user, or just enabling the root account and using su root to gain root access?

For a single-user system, there's not much difference between the two from a security perspective: in either case, the attacker needs to guess one password to gain superuser privileges.

The big difference shows up in a situation where you've got multiple administrators.  In that case, requiring sudo creates an audit trail of exactly who performed which administrative action.


Is HTTPS still secured with a known server certificate (private key)? I see that some product are shipped with a default server certificate.
I guess that a lot of these installed products still use the default server certificate in a real environment.

If your server certificate is known (eg. someone know which server certificate you are using and can download it), is your HTTPS still secured even if nobody can access your server(s) ?

In another point of view, is HTTPS or SSL with a 'public' server certificate can be called 'security' ?

To get terminology straight: the certificate is the public part. It is public so everybody knows it, and when a client connect to a SSL server, that certificate is one of the first things that the server sends to the client. What you mean is: when the private key is not really private, can SSL still be considered as "secure" ?

The answer is basically: No.

However, there are subtle details. When client and server talk to each other, they agree on a set of cryptographic algorithms to use, called the cipher suite. See the standard for (most of) the currently defined cipher suites. One of the elements of the cipher suite is the key agreement method used to exchange the "pre-master secret" from which all other keys are derived. When the cipher suite is a basic "RSA" suite (i.e. the cipher suite names begins with "TLS_RSA"), then the key agreement is basic asymmetric encryption with RSA: the client generates a random pre-master secret, encrypts it with the server's public key (from its certificate), and the server decrypts it to recover the pre-master secret.

When the server's private key is known to an attacker who merely eavesdrop on the channel, then that attacker can also decrypt the message from the client, obtain the pre-master secret, and decrypt all the data. It seems safe to say that, under these conditions, there is very little security left.

However, if the negotiated cipher suite is of type "ephemeral Diffie-Hellman" (the name begins with "TLS_DHE"), then the actual key agreement uses Diffie-Hellman with public/private DH key pairs which have been randomly generated on the spot. The server's private key (the one which is hardcoded and thus not very private at all) is used only to sign the DH public key. Under these conditions, a purely passive attacker, who merely spies on the data packets but does not interfere, will not be able to get the pre-master secret, and the connection will remain secure. This feature of DHE is called Perfect Forward Secrecy.

However, even with DHE, an active attacker can impersonate the server and mount a Man-in-the-Middle attack, voiding any security. PFS is an actual advantage only when considering the case of a private key ulterior theft, where the attacker steals the server's private key after the connection has occurred. At that time, it is too late for the attacker to be "active", and PFS locks him out. But this is not your situation: you envision a case where the attacker already knows the server's private key when the connection happens. The attacker can then mount an active attack.

So, to sum up: when the server's private key is known to attackers, then security is maintained only against passive-only attackers, and then only if the client and server agree on a DHE cipher suite.

(Strictly speaking, security can be salvaged even against active attackers if the cipher suite is DHE and the server requires a client certificate and the client private key is not known to the attacker. That's an edge case.)


How to deal with found security issues on third party websites? Some time ago I discovered a security flaw regarding the password policy of my cellphone provider which basically makes the website, which includes access to personal information and invoices, vulnerable to brute-forcing (in a significantly short amount of time) and DoS. I reported it to their customer support but they didn't really care about. I was contacted by a technician telling me it's not a big deal but they will look into it. Now, months have passed and nothing has changed.

My question is:
Are there any best practices how to deal with this situation (especially forcing the company to fix the issue and protect others) without me getting sued?
If publishing the issue is an option: Where should I do that? (I don't have a blog, so that's not an option.)

You can report it to CERT using this form below. Depending on the vulnerability, CERT will contact the vendor on your behalf:

https://forms.cert.org/VulReport/

Here is a quote from the link above for your reference:

  If you believe you have found a security vulnerability that has not
  been resolved, please complete the following form. As our
  vulnerability disclosure policy explains, we send information
  submitted in vulnerability reports to affected vendors. By default, we
  will share your name with vendors and publicly acknowledge you in
  documents we publish. If you do not want us to share your name or
  publicly acknowledge you, select the appropriate responses in the
  form.

You can also reference the CERT policy for disclosures here:

http://www.cert.org/vulnerability-analysis/vul-disclosure.cfm

If CERT does contact the vendor the vulnerability will be disclosed after 45 days per the first paragraph from the link above:

  Vulnerabilities reported to the CERT/CC will be disclosed to the
  public 45 days after the initial report, regardless of the existence
  or availability of patches or workarounds from affected vendors.


Thunderbird - what happens if Gmail SSL cert gets spoofed? I use a good MUA: Thunderbird [to read/reply to my emails on Gmail].

So: what happens, if i go to a place, where is public wifi, and someone tryes to sniff my password/username/emails?

Questions:
 - Is gmail available only via IMAP/SMTP with SSL? [sslstrip-like attack could get my passwords?]
 - if someone spoofs "smtp.gmail.com", then Thunderbird will notice, and complain about that the SSL cert is bad?

If someone could clear this in my head i would be happy:P

Thunderbird will complain if it gets a "wrong certificate". A "wrong certificate" is a certificate that either contains the wrong name (i.e. it does not designate the expected server name), or cannot be validated by Thunderbird (not signed, directly or indirectly, by a root CA that Thunderbird trusts; not valid at the current date; or any of the other hundred tests which lurk deep in X.509 validation process).

Thunderbird, by default, trusts about 80 root CA. Claiming that none of them may be bribed or conned into emitting a fake certificate is a kind of leap of faith. You can, though, trim that list at will (Preferences -> Advanced -> Certificates -> View Certificates).

Also, when Thunderbird complains, it does so in a non-fatal way: the user can still override, and it is as simple as clicking on a "do it now you moron" button. Refusing the certificate means not reading your emails; the email-reading urge is such that many users will readily bypass the security warning without remorse, often without even reading the warning message.


Do virus author's purposely speak in broken English to avoid linguistic evidence? Are there any examples of native English speakers creating a virus with broken English on purpose?

False flagging is a common methodology to throw off defenders when trying to attribute TTP’s.


MIME sniffing protection As it is known, older versions of MSIE (before 8) have a nasty habit of treating images as HTML if they "look like" HTML, which can lead to nasty vulnerabilities for sites that allow people to upload images. Even though it is fixed in IE8, there's still a lot of IE7 and before around, so this needs to be addressed.
So the question is, how it is best to address it, given:

PHP site with file uploads
Not recoding images (i.e. stuff like ImageMagick can't be used)
Direct access to images should be allowed
We can not prohibit people from using "wrong" extension

Would checking first 256 bytes for something like <(html|body|img|script|head)> be enough? Any better ways to do it?

http://www.adambarth.com/papers/2009/barth-caballero-song.pdf is a excellent overview reference of the problem. It is not only for images, also for txt files and others...


Why does arp spoofing on a local network 'break' internet access for the victim? I'm doing some experimenting with Kali on my home network and was wondering about something regarding ARP spoofing.

When I ARP spoof another device AND the default gateway, Internet access stops working for said device. To get it working, I must enabled the http & https proxies.

What I'm trying to figure out is why does it break? My understanding of the ARP spoofing process and traffic flow is:

After succesful arp poisoning, the end device sends constructs its packet destined for a web server living on a public IP address. The frame header shows my device as the target MAC address

When I receive the frame, it is my understanding that I will simply rewrite the destination MAC address and sent the frame back out the interface
The gateway will receive the frame and rewrite the IP header (NAT) and send it out to the internet
When the gateway receives the reply, it consults the NAT translation table and rewrites the destination IP address. Gateway then checks its ARP table and sees me as the target MAC address for the arp poisoned devices IP address
Gateway writes the frame and my MAC adddress is down as the destination
I receive the frame, and then rewrite the destination MAC address so it still gets to the original source device

So, with that in mind, i'm struggling to understand at what point external communications break down?

"It breaks cause you dont forward the packets"

Basically in an ARP spoof attack you tell the victim you are the router and to the router that you are the victim.So all the traffic basically flows through you.But you need to enable ip_forwarding to actually transmit packets from your device to the router,that is why it "BREAKS" the internet for the victim,cause you are not forwarding the packets to the router and back.


What is the correct way to implement anti-CSRF form tokens? I am fully aware of CSRF and have already implemented some safe forms, but I have never been happy with the results yet.

I've created tokens as a md5 of username, form info and a salt and stored it in a session. This has a problem with tabbed browsing (can be fixed by keeping an array of active hashes) and with timing. I would like my hashes to work only for eg. 10 minutes, but how do I put a time-related variable in the hash?

Can anybody point me to a good resource describing how to make CSRF security properly?

There is a good explanation on OWASP: OWASP CSRF Prevention Cheat Sheet

In short they say that there are two ways:

Add a random token to each user session. Only if this token is present and correct will the changes be applied, otherwise the request should be rejected. It is important that the token is only sent with a POST request, since GET requests can leak the token to different places (browser history, log files, etc.).

It is also possible to generate a token per request, but this leads to usability problems. For example the back button wouldn't work properly anymore. But of course the security would be increased.

Also make sure (to enhance security even more) that the token is only sent over TLS, so there won't be any man in the middle problems.
The other option is to use some sort of challenge - response (for example CAPTCHAs or one-time tokens).

The OWASP-Page also lists a few measures that don't work. These are

Using (secret) cookies
Not using GET-requests
Multi-Step transactions
URL Rewriting


Who sells IP reputation data sets? I know of many companies that will sell ability to lookup IP/URI reputation. Be it DNSBL, json/*, returnpath, threatstop, surbl, ..., will let me perform lookups for a reasonable fee but, in case of this particular project, the lookup introduces unacceptable latency.

Do you know of anyone who offers a dataset that is meant for local integration and a periodic update service? I understand that the update lag will make the local database permanently out of date, but this is a tradeoff I have to accept.

Spamhaus.org do this for free.

The other main companies that do this (trusteer, markmonitor etc) do provide feeds of various types. Well worth asking them what type of feed you can get from them. Of course, they will all be cost options.


Can an air-gapped PC receive malicious code even when completely clean, apart from all physically attacks? The Basic question is in the title there are more questions bellow but it is in context of the question in the title...hopefully

What i have read is that it can eavesdrop the Airgap PC via

acoustic
light
seismic
magnetic
thermal
radio-frequency
physical media

I also read that it can receiving data but only if it has already been infested with malicious code so it has an kinda receiver on it to communicate.
https://arxiv.org/abs/1804.04014 (Powerhammer). "In this case, a malicious code running on a compromised computer"

But what if the Airgap PC has no malicious code on it and it is completly manufactory clean? Apart from trusting all the factorys that are involved in the whole process of building that PC, apart from sneakernet updates/patches (I probably have to do it at some point but that is irrelevant), apart from all physically attacks.

I mean it more like is it with an know airgap attack (excute code on victims air-gap PC via magnetic, thermal etc., not eavesdrop) possible even though, again, there is no receiver (malicious code) on it.
If im not wrong to communicate there has to be always a transmitter and a receiver?

I am just wondering because of PC components like WLAN-cards, do it has to been removed at hardware, or can it still be there without worrys?
Can code just jumping on the invisible WLAN signal even though there is theoretically no signal because software-wise everything is turned of or is not installed (Hardware WLAN card is there but its not used)?

Attacks on airgapped computers will only work after the computer is compromised. It is used to leak information from the infected computer, not as a covert channel to remote control the computer.

An airgapped computer without any communications device active (no wifi or bluetooth, no Ethernet cable connected) and without access to removable storage is pretty secure.

Code cannot magically jump inside the computer, it must be received somehow. If you exclude networking and removable storage, and no physical attack occurs (like someone typing malicious code by hand), the computer will continue clean.

I would remove wifi and bluetooth, as they could be used if there are any exploit capable of attacking the radio subsystem. The probability is low, but not impossible.


Unecrypted connection to server - safe? I am using heroku and cloudflare. I am going to release my website but I don't want do it without SSL.

Now I always need an heroku addon to add my SSL certificates which costs $20/month.

Cloudflare enables SSL over DNS but I am a little bit curious. (So I don't need to get the heroku addon and can safe those $20/month)

What I think will happen looks like this

(user)-> [https]-> (cloudflare ssl)-> [http]-> (myserver)

Wouldn't this completely destroy the purpose of SSL?

I mean , can other user access the unecrypted http connection?

Update1:

I spoke to cloudflare and they told me that the only way for unauthorized people to get the unencrypted data is to hack the cloudflare servers, so I am on the safe site.

Can anyone confirm this?

It is not like CloudFlare has not been hacked before. See this.
Also, since SSL is getting terminated at CloudFlare this means that data is going in plaintext from CloudFlare to Heroku. So anyone in the path to Heroku from CloudFlare can "see" data.


Determing live hosts past a restrictive firewall with nmap Sometimes when I am doing an external security assesment, I run into hosts that have the following restrictions/configuration:

All ICMP traffic is blocked
An IDS or some device returns all ports as filtered when scanning with nmap, using sT, sN and sS scans.
Even running at -T0 or -T1, any port is returned as filtered. Scanning a single port, eg -p 65544 before doing a full scan shows it as filtered also.

Only a very small percentage of hosts will seem to be actually up, i.e. having a port accessible on the server.

The problem with the IDS reporting many ports as "filtered" for a host means nmap considers it live.

Sometimes I run into this problem with very very large ranges. Determining the amount of live hosts can save time on the assessment, and so I am looking for a way to automate in some fashion.

If the only answer to to only use hosts that have at least one port as "open", is there a way to script nmap to ignore ports considered "filtered"?

I should also note, ARP is not an option here due to this being an external scan across the internet, and there is no pivot point.

Have you tried using the --open option in nmap to show only open ports? It might be worth reading the nmap output man page.


apache mod_isapi public exploits In public apache mod_isapi exploits, they ask for dlls, and I am unsure what I should put in dll.

I am having a hard time understanding exploits.. How does all of dlls connect to manipulating isapi.dll?

By default, metasploit requests /cgi-bin/SMTPSend.dll

The idea is that the DLL is forced to be unloaded by the server then requested again by the attacker, resulting in a potential violation of the memory pointer because mod_isapi doesn't properly cleanup the pointers to an unloaded DLL.


Vulnerability Scanner vs Security Audit I have a web app, and customers who are concerned about the security of the app. I want to be able to give my potential customers (manufacturing companies with 2k-10k employees) confidence that our app is secure.

One thing I'm considering is subscribing to Qualys security scanning. I'm hoping that the knowledge that we are using a well known service for security scanning would belay some of my customers concerns. I could potentially even show them the Qualys generated reports.

Is Qualys a good solution for this problem? Would IT staff at my customers have likely heard of Qualys? Would I be better off just getting an external security audit by a well known security firm?

It sounds like Qualys is probably your preferred option: ongoing and repeated vulnerability scanning provides a long-term security blanket which will comfort your customers.

That being said, you should understand the difference between vulnerability scanning and a targeted security audit (often "pentest").

Vulnerability scanning will make sure that your infrastructure is, and stays, secure.  It will detect when you the web server software you're using suddenly becomes vulnerable because someone released a new attack against it.  It will detect if your server starts offering FTP to the world.  It will notice if certain known vulnerable configurations of the web server show up.  What it won't do is provide any real insight into the security of your application.

That's what a pentest does.  The pentester will look at your application with experienced eyes and specialized tools, and try to discover if you made mistakes when you wrote the application that an attacker could capitalize upon.  They'll also look at the same sort of "vulnerability scan" things, but the real value-add is to have a human think things through.  People can make connections that computers can't, recognize patterns that indicate subtle problems.

So in an ideal world, you'd have your application pentested at the start, and again whenever you make major code changes to it.  And you'd also have Qualys (or an equivalent, of course) run regular vulnerability scans to look out for all the simple, straightforward stuff that regularly bites people in the posterior.

If you're just checking a checkbox, though, that's more money and effort than you're looking to spend.  Go with the regular vulnerability scanning, you'll get the seal of approval to show people and you'll get helpful defense against the "low hanging fruit" - easy for attackers to find, usually easy to fix.


POST request in curl return all the source code of the page I am trying to exploit the mutillidae web-application and I found a page vulnerable to sql injection but with a blacklist check embedded into the HTML code.
I've tried to bypass this by forging a POST request with CURL but I don't know why it return always all the html source code of the page.
The command I use is this:

curl -X POST --data 'username=\'%20or%20\'1=1&password=\''  http://myinternalip/mutillidae/index.php?page=login.php

Thanks for everyone who'll answer.

edit:
i've tried to change the command to:

curl --data "username=\'%20or%201=1%20--" http://myinternalip/mutillidae/index.php?page=login.php

cURL will display exactly what the server provides as response, by default. In this case, the server is responding with a full HTML page. This doesn't mean that the SQL injection did not work, merely that the output even from the injected request was a full HTML page.

It is common for the response from an injection attack to appear in part of a page, perhaps a table which is drawn from a database in some way, or in a field loaded from a database query. Tools like SQLmap perform automatic comparison between "legitimate" requests and injected requests, looking for differences. It is possible to do the same manually, but the key in most injection attacks is the input string, rather than analysing the differences in the output.

Using a proxy such as Burp or ZAP allows you to edit post requests directly, and see the responses in a browser, bypassing any client side protection that may be in place. You can also extract specific parts of the page which are of interest using Burp's Intruder module's extract function - by injecting an uncommon string, it is possible to quickly zoom into the changed part of a page.


Open Backdoor in web browser using xss? I am trying to learn about of xss attack and so I far, I understood that a successful attack result in the attacker capable of injecting malicious js in the victim's browser. If my understanding is correct, this attack will give him access to browsing data of a compromised domain only. For example, if the compromised domain is example.com attacker will have access to cookies and local storage  .... of example.com
But so far, injected code executes immediately. Is it possible that
an attacker injects a code that

Permanently eavesdrops the user HTML code and browsing activity on that
single domain

Execute some malicious code at a later time or when a condition is met? (for example, if user balance > $999 assuming example.com is an internet banking app?

If this is possible, where does the attacker store the js code? I am looking for what keywords should I google about this code of exploit.

If I understand your question correctly, you are asking how to persistently compromise a whole domain with XSS, and not just a single page, to be able to execute malicious code in every page at any time.
Suppose you have one page, vulnerable-page.php, where you can inject JS code persistently, that is, every time a user loads the page the malicious code will be executed. If the victim visits non-vulnerable-page.php though, your code won't be loaded. There might be some tricks you can use anyway, for example you can make vulnerable-page.php look and behave like non-vulnerable-page.php, so the victim will think they are on non-vulnerable-page.php while in reality they are still on the vulnerable page. You could even expand this concept and devise a kind of front-end proxy, so that the victim will think they are browsing the website, while in reality they are always staying on the vulnerable page (the vulnerable page will load the content of the other pages with AJAX, and maybe also change the path in the address bar). You can use similar clever tricks to obtain the information you want, but your mileage may vary.
Now suppose you find a stored XSS vulnerability in the footer of a website, and that footer is included in every page: home page, articles, login page, admin panel, etc. In this case you will be able to inject your code everywhere all the time, and therefore execute any JS you want, wherever and whenever you want.
In several cases though, an attacker doesn't need to be able use XSS in every page to be able to compromise a website completely. For example, the attacker can make a logged-in admin visit a single compromised page on the website: that page might send an AJAX request to change the attacker's privileges (upgrading the account from "guest" to "admin"), and from that point on the attacker will just be able to do whatever they want from the admin panel (including installing malicious modules, changing files, etc.). This is just an example to show you that often a single vulnerable page can still lead to complete compromise.


NAT separate firewall or other security tools It's a conceptual question:

Suppose i want to separate NAT and firewall, can it help to my security?

INTERNET >>>> NAT >>>> Firewall >>> MyNetwork

I don't think it would make much of a difference. NAT has nothing to do with security and the firewall should be your primary defense.

Having a device provide both firewall and NAT services isn't a security risk by itself. The only potential security risk would be the software and configuration of the device. Since there are so many vendors/products on the market and questions about products is disallowed, this cannot be answered anyways.


Prevent a remote privilege escalation when the root/admin password is known Consider the following Linux system:

root account is disabled (passwd -l root, passwd -d root),
there is an account 'admin', with sudo rights,
there is an account 'webservice', with limited privileges, and no sudo rights,
su is disabled via PAM (auth required pam_wheel.so),
only 'admin' can SSH into the system (AllowUsers directive, only with a key, no password accepted),
'webservice' runs some web services which has been compromised: an attacker can now run remotely any shell command as the user 'webservice',
the attacker has no physical access to the device,
finally, the attacker knows the 'admin' password, but not admin's SSH key

How could the attacker run a command as 'admin'?
My understanding is that the attacker cannot sudo, cannot su, cannot SSH, even if the admin password is known, so no privilege escalation is possible. Is that correct? My objective is to understand the consequences and the possible mitigation (if any) of having an admin password compromised.

You should make sure that no other service allow login with username and password. Some systems have an active telnetd or ftpd by default. Ftp would be enough because it would allow to overwrite admin's authorized_keys file.
You should also control that exec login is not possible in your system from a simple shell.
Finally you should control that webservice is not allowed to write files in any directory where admin or root could try to execute files (the dangerous . in PATH for example).
Those are just the first possible vulnerabilities I could think of. Do not hope that list to be exhaustive...


What are the best algorithms against known plaintext attack? I'd like to encrypt files and their metadata as well. They will be stored in some sort of database (not yet decided, probably pgsql). The metadata can be for example the creation time, the modification time, etc, so it is well guessable e.g. a datetime string or a timestamp. Afaik this makes finding the key with brute force easier. Since there will be many files encrypted with the same key, I was wondering what algorithm might be the best to encrypt the files and the metadata?

I was thinking on workarounds too, for example storing the datetime string in a JSON format along with a random value:

{
    modificationTime: "2017-11-18 03:54:11",
    bik2rbfih2ofbskblwbf: "sdfgjhln2rh9328hogolwesgn"
}

Following this line of thought I could add the whole metadata to a single column, so it would be even harder to guess, but on the other hand harder to query too.

{
    label: "blah",
    description: "blah blah",
    tags: [1,2,3,4,5],
    modificationTime: "2017-11-18 05:21:11",
    creationTime: "2017-11-18 03:54:11",
    sfbik2rbfih2ofbskblwbf: "sdfgjhln2rh9328hogolwesgn"
}

Another thought was to encrypt the metadata and the actual data with different keys. Any suggestions, best practices in the topic?

Short answer: Any modern considered-secure symmetric cipher is fine. Just use AES with a secure mode of operation, like CBC or GCM.

Known plaintext attacks are a standard part of cryptanalysis; any cipher that is even marginally weaker against them than otherwise is considered cryptographically compromised.

Longer answer: This is an excellent risk to consider, but you're kind of asking the wrong question. Leaving aside the why (that is, why are you trying to roll your own data encryption scheme, when so many already exist?), you should probably consider where the assumption that

  this makes finding the key with brute force easier

comes from. Even if you HMAC the data with a different key (not possible if using an authenticated encryption scheme like AES-GCM), if you have any way to determine a correct key from an incorrect one (such as a hash of the key, or of the plaintext, or even just because you make the assumption that if it decrypts into syntactically-valid JSON the key is probably right), an attacker can do the same thing. Being able to near-instantly validate the correctness of the correct key is just assumed to always be the case.

The difficulty of brute-forcing modern crypto isn't because you don't have a partial plaintext in systems that use it, or because it's hard to know when you've guessed the right key. It's because the key space is so large that, if you built an entire datacenter full of top-of-the-line hardware that did nothing but try a distributed attack to brute-force a single 128-bit AES key and could run forever, the machines in that datacenter would be absurdly unlikely to guess the right key before the sun expanded to swallow the earth.

That's not hyperbole, by the way; human intuition is just really bad at big numbers, and 2^128 is an extremely big number. Let's say you put a million (OK, 2^20) CPUs in the hardware in that datacenter. Let's further assume that each of them can check 32 billion (2^35) possible keys per second (which is faster than even the best hardware-accelerated modern commodity CPUs I'm aware of, but you've got some fancy custom hardware). That means your whole datacenter can check 2^55 (about 32 quadrillion) possible keys per second. Super fast, right? At that rate, and assuming that on average you only have to search half of the keyspace, you will need (2^127)/(2^45) = 2^82 seconds to have a 50% chance of finding the key.

The sun is expected to swallow the earth in roughly 7.6 billion years (give or take a few thousand millennia). In seconds, that's 2.4x10^17, also written as 2.4e17. Take the base 2 logarithm of that number, and you get a bit less than 58. 2^82 / 2^58 is 2^24, or about 16 million. You would be roughly one six-millionth of a percent of the way done.

Also, not part of your question, but: you are taking into account integrity (detecting tampering with the ciphertext, which most encryption provides little if any protection against) and also generating unique initialization vectors for your files, right? Doing crypto right is hard. There's already (tons of) programs out there that do symmetric encryption of files (or other data blobs).


How do certificate issuers become trusted? From what I understand, the certificate scheme that TLS/SSL relies on works because your computer has trust for major CA issuers built into it.

That is, your OS is installed with certificates for some of the major signers.

I have so many questions about this, but I'll start with the most basic:

Does this mean it is impossible to add new trusted certificate issuers forever? Is it impossible for one to start his or her own root CA without the consent of computer manaufacturers?

Also, what is stopping an attacker from simply installing "trusted" certificates in people's computers?

Is it impossible for one to start his or her own root CA without the consent of computer manaufacturers?

Everybody can create it's own CA and install it on all computers s(he) has control to. It is not unusual for larger companies to have their own internal CA.

  Also, what is stopping an attacker from simply installing "trusted" certificates in people's computers?

Existing security measures should in theory make it impossible for an attacker to install additional certificates on machines owner by others. But if the attacker manages to get access to the machine (malware, physical access, deal with the vendor...) adding another trusted CA is possible. This is actually done in practice, see Superfish.

Apart from attacks new trusted root CA gets typically added in companies to support their own infrastructure or to make analysis of SSL traffic in firewalls possible (SSL interception). For SSL analysis also several personal antivirus solution install such new root certificates.


"john --format=md5" caused "Unknown ciphertext format name requested" error This is known md5 hash for Kioptrix: Level 1.1 (#2)

Linux unshadow file

wolf@linux:~$ cat md5hash.txt
root:$1$FTpMLT88$VdzDQTTcksukSKMLRSVlc.:0:0:root:/root:/bin/bash
john:$1$wk7kHI5I$2kNTw6ncQQCecJ.5b8xTL1:500:500::/home/john:/bin/bash
harold:$1$7d.sVxgm$3MYWsHDv0F/LP.mjL9lp/1:501:501::/home/harold:/bin/bash
wolf@linux:~$

md5hash only

wolf@linux:~$ cat md5hash_only.txt
$1$FTpMLT88$VdzDQTTcksukSKMLRSVlc.
$1$wk7kHI5I$2kNTw6ncQQCecJ.5b8xTL1
$1$7d.sVxgm$3MYWsHDv0F/LP.mjL9lp/1
wolf@linux:~$

Since I know that these are md5 format, I used --format=md5 option in john.

Unfortunately, I'm getting  Unknown ciphertext format name requested error.

wolf@linux:~$ john --format=md5 md5hash.txt
Unknown ciphertext format name requested
wolf@linux:~$

wolf@linux:~$ john --format=md5 md5hash_only.txt
Unknown ciphertext format name requested
wolf@linux:~$

I've verified that the format is similar with pentestmonkey cheat-sheet

Any idea what's wrong here?

What version of your John?

kali@kali:$ john | head -3
John the Ripper 1.9.0-jumbo-1 OMP [linux-gnu 64-bit x86_64 AVX2 AC]
Copyright (c) 1996-2019 by Solar Designer and others
Homepage: http://www.openwall.com/john/
kali@kali:$

For version 1.9, there are a few types of md5. md5 only are not one of them.

kali@kali:$ john --list=formats | tr , '\n' | grep md5
 md5crypt
 md5crypt-long
 asa-md5
 dmd5
 krb5pa-md5
 net-md5
 md5ns
 pix-md5
tcp-md5
kali@kali:$

If you're not sure of your hash type, use hashid tool

kali@kali:$ hashid '$1$FTpMLT88$VdzDQTTcksukSKMLRSVlc.'
Analyzing '$1$FTpMLT88$VdzDQTTcksukSKMLRSVlc.'
[+] MD5 Crypt
[+] Cisco-IOS(MD5)
[+] FreeBSD MD5
kali@kali:$

This is actually MD5 Crypt

kali@kali:$ cat hash.txt
$1$FTpMLT88$VdzDQTTcksukSKMLRSVlc.
$1$wk7kHI5I$2kNTw6ncQQCecJ.5b8xTL1
$1$7d.sVxgm$3MYWsHDv0F/LP.mjL9lp/1
kali@kali:$

Try again ... voilà

kali@kali:$ john --format=md5crypt hash.txt
Using default input encoding: UTF-8
Loaded 3 password hashes with 3 different salts (md5crypt, crypt(3) $1$ (and variants) [MD5 256/256 AVX2 8x3])
Will run 2 OpenMP threads
Proceeding with single, rules:Single
Press 'q' or Ctrl-C to abort, almost any other key for status
Almost done: Processing the remaining buffered candidate passwords, if any.
Proceeding with wordlist:/usr/share/john/password.lst, rules:Wordlist
Proceeding with incremental:ASCII


Memory Protection Unit/MMU in context of multiple cores and security issues There is a chipset I am working with that utilizes an ARM cortex -A7 as the Application processor and an ARM 9 Baseband processor.

I had a major concern since the ARM cortex A7 is utilizing android that the MPU and/or MMU could be subverted to see the whole DRAM which includes the ARM9 side as well. Although the architecture seems to suggest they are utilizing an MPU my concern is that the since the android kernel can be subverted that the MPU could be reconfigured at runtime to remove the restrictions. The concern is not just that the Android kernel of this embedded device could be rooted but that privileged escalation could occur so that a kernel process at runtime could modify the MPU registers (i am guessing). Although these processors do have trustzone however nothing out of the chipset has been created which means that there is no concept of NSbit to delineate between secure vs non secure world.

What kinds of vulnerabilities i could be looking at and if my concerns are legit?  lastly, the device has secure boot but its the Applications processor side that I have serious concerns about and of course in runtime. Any help with potential vulnerabilities and/or solutions would be appreciated.

All the SoC's I've seen with this configuration have handled this situation by having MPU registers only writable from the "secure" baseband processor or from within TrustZone. As you wrote it's virtually impossible to keep the application world from getting hacked/rooted, but as long as the MPU(s) cannot be reconfigured from the Linux kernel then you still have reasonable protection. I don't agree with the statement that the non-opensource micro kernel would be any more secure though - plenty of vulnerabilities in baseband code...

Edit:
I haven't worked with the Qualcomm MSM8x10/8x12 (Snapdragon 200 family) specifically but the architecture looks very familiar to the more powerful Snapdragon 400/600/800 chips with xPUs (Protection Units) all over the place (protecting memories and peripherals).

Also I would be very surprised if the NS-bit isn't respected (it is dealt with in all other Snapdragon SoCs I've worked with). The details of the security solution is something that Qualcomm will have to disclose to you through the normal support channels though.

As far as attack vectors go there have been a lot of different approaches, everything from utilizing JTAG interfaces that people forgot to disable to very advanced attacks on the low level software. In the end it all depends on how interesting of a target your application is - cellphones have traditionally been a high-value target where people are trying to gain access to the baseband to change the SIM-lock and/or the IMEI/MEID number. Most hackers these days are more concerned about gaining full access to the application side (rooting), so as long as you're not making that too difficult hopefully they will leave you baseband alone.

If the security has been set up correctly then obtaining access to the TrustZone Trusted Execution Environment (TEE) memory on the application side and access to the baseband memory should be very difficult from the non-secure world. There's no way the chipset will be approved for the more serious DRM schemes if this wasn't the case.


Can lower level intermediate cert declare SAN that broader than higher level cert? Suppose 1st level intermediate cert specifies DNS=www.dev.com
Can 2nd level intermediate cert which is signed by the 1st level specify DNS=*.dev.com or maybe DNS=*.dev2.com?
Does certificate level affect SAN in any way?

In a given setup -- it is working configuration. Subject Alternative Names are constrained through different means -- Name Constraints extension in CA certificate. If you do not use Name Constraints, you can use whatever name you want in any certificate.


How to conclude from a target IP to associated URL(s)? Given a target IP or target IP(s). Is there any reasonable way to conclude from the IP to hosted URL(s).

I can scan the IP(s) with nmap and possibly conclude on which ports a webserver is running, but not which URL(s) may be served there.

I could also simply access the IP in the browser with the identified ports and see if there's are default redirect in place.

Is there a reasonable way to conclude from IP to hosted URL(s)?

edit: I'm not talking about directories of one hosted URL (e.g. example.com/uploads, example.com/images, ...).
I'm talking about the scenario, when multiple different URLs are hosted via one IP address (e.g. IP 127.0.0.1 hosts example.com and somethingelse.com).

I do know about reverse DNS searches, but are there any other techniques?

Crawlers can find these over different ways:

Read sitemap files or the robot.txt
Use statuscodes like 403 or 404 to guess whether there is a file or not


OWASP Recommendation on Client-Side Password Hashing The OWASP Application Security FAQ recommends the use of JavaScript to produce a salted hash of the password client-side with JavaScript prior to sending it to the server.

Is this something truly advocated?
Should I go this route, how should the page behave should JavaScript be disabled? I imagine that signing in will be disallowed?

By storing a staled hash of the password and then using this same hash as an authentication token,  an application is more vulnerable to attack because this application is now storing authentication credentials in plain-text.   An attacker can use SQL Injection to read this hash and then authenticate without having to crack the hash to obtain the plaintext password.

The OWASP wiki entry refereed in this question was misleading and was removed:

  Here is how the salted MD5 technique works: the database stores a MD5
  hash of the password. (MD5 hash is a cryptographic technique in which
  the actual value can never be recovered.) When a client requests for
  the login page, the server generates a random number, the salt, and
  sends it to the client along with the page. A JavaScript code on the
  client computes the MD5 hash of the password entered by the user. It
  then concatenates the salt to the hash and re-computes the MD5 hash.
  This result is then sent to the server. The server picks the hash of
  the password from its database, concatenates the salt and computes the
  MD5 hash. If the user entered the correct password these two hashes
  should match. The server compares the two and if they match, the user
  is authenticated.

MD5 is not appropriate for passwords.  This is a broken primitive and a violation of CWE-916.   Even if this was describing a secure challenge response, HTTPS is a more appropriate tool and is required to protect the session id.


How can I set up signed downloads? Scenario

I have a web server that authenticates and redirects from HTTP to HTTPS. Clients can then view available "downloads" in their account. I want to be able to sign these download links - as in, I want the link to only be used by the authenticated user, only once, and I want to be able to recover information about when a specific "token" was used...

Question

What is this actually called? I can't seem to find anything about it, and I'm sure I've seen it before. I just need to find out what it's called or what a resource is regarding it so I can read about it and implement it.

As a bonus question: does anyone know offhand how to implement public key authenticated database connections in PHP (like mysql_connect(); or whatever, but when the database is on the local network instead of the same machine, and you don't want the connection sniffable)

I don't know about the terminology, but restricting access to a download link is simple. For example, (assuming a LAMP environment), you could generate a download hash(token) for each user-download page pair. Now, on the download page, check if the logged in user (extracted from $_SESSION) has access to the given page (using MySQL), and check the hash (from $_GET). You let the user download the page(Using header('Content-disposition: attachment') followed by readfile($filename);), and then revoke access to the given token by removing it from the database.

However, since you are redirecting from HTTP to HTTPS, the session will change. In this case, you can propagate the session by passing the id via GET/POST using the technique described here.

Though having an HTTP login for an HTTPS page is rather bad practice: the password/etc can still be sniffed by the middleman.


Fortify360 - Sinks & Sources - Vulnerability count In an application security environment, I use Fortify Software's Fortify360 on a daily basis.

One of my biggest hurdles is explaining the numbers (sources vs sinks)

Fortify flags each location in the source code where unvalidated data is displayed to a user as a Cross-Site Scripting vulnerability.

  Let's assume there are 300 locations (sinks) where unvalidated
  data is displayed to the user.
  Of those 300 sinks, the data is ALL pulled from a database utilizing
  one function. (source)

Fortify will subsequently report that there are 300 Cross-Site Scripting vulnerabilities. What it doesn't explicitly tell you is that 300 of which may potentially be fixed from the same location.

My question to you, from an Application Security Engineer point of view, do you then report to your client that there are 300 Cross-Site Scripting vulnerabilities, or 1 Cross-Site Scripting vulnerability? Are either of those statements accurate?

Do you report the source, or the sink?

What I am currently doing is reporting that there are 300 POTENTIAL Cross-Site Scripting vulnerabilities which may all be fixed within one function/method.

Is it more accurate to say that there is 1 Cross-Site Scripting vulnerability which is exposed in 300 locations?

I realize some of this is subjective, but I'm looking for input from others in the field who can shed some light on their methods.

I'd reiterate AviD's reply - Cross Site Scripting is generally better solved as a context sensitive output encoding problem, rather than an input validation problem. If you're trying to solve it as an input validation problem, you're going to be encouraging a black list input validation approach in many cases, or if you're using a white list approach you may not be able to get these as tightly constricted as you'd like.

Also - what you'll need to handle for each output encoding context (HTML, attributes, CSS, JavaScript) will be different, so I'd advise you steer the development team to something that does the encoding for them like Microsoft's WPL (Web Protection Library) or OWASP ESAPI or OWASP Reform for other languages.


Is XSS via MIME sniffing a Stored or Reflected XSS? The title says it all. I understand how to exploit XSS via MIME sniffing, but the question is, do you call this type of XSS stored or reflected?

OWASP says

  Stored attacks are those where the injected script is permanently
  stored on the target servers..
  The victim then retrieves the malicious script from the server when it requests the stored information

While, reflected attacks usually require some user interaction, like clicking a malicious link for example.

It's a little confusing to me on what type of XSS this would come under. I could modify my file to have some javascript at the beginning, have the browser interpret it as a JS file and execute. Does this make it a stored XSS?

XSS attacks using MIME sniffing could be both stored and reflected. Anything where the browser is tricked into believing that a file with one MIME type should actyally be interpreted as something else could be called a MIME sniffing attack. If the piece of evil data that tricks the browser comes from the URL, we would call it reflected. If it is stored on the server, we would call it stored.

In practice though, I would expect most (almost all) MIME sniffing attacks to be stored. The traditional way of doing it is that you exploit a file upload functionality that e.g. only accepts images by uploading a file containing JavaScript code in the hope that browser will ignore the image MIME type and go with a script one instead. This line of attack clearly relies on the payload being stored on the server, so it would be stored XSS.


Does the e-mail send from an id to the same id requires encryption and other security checks? I have noticed that Gmail is not encrypting the mails send from an id to the same id (When From address and To/Cc address are same).
Is encryption really required in the above scenario?
Necessity of other security protocols check?
Background : I could not find the encryption details in the tag security:   Standard encryption (TLS) and below checks are not done while checking the original message.

Sender Policy Framework (SPF)
DomainKeys Identified Mail (DKIM)
Domain-based Message Authentication, Reporting and Conformance (DMARC)

It depends. If you address a snail mail letter to yourself (i.e. same sender and recipient) and put it into a public letterbox than its probably better to close the envelope (i.e. protect the letter). If you instead live alone and leave the letter to you on your own kitchen table, then protection is likely not needed.
If you send a mail to yourself using the GMail web interface then there is likely no "normal" mail transport (i.e. SMTP) involved at all. This means anything like SPF, DKIM, DMARC and SMTP encryption play are irrelevant and you will not find any traces of it. Even if you directly connect with authenticated SMTP to Google's mail server to deliver the mail, SPF, DKIM and DMARC are not relevant. These are only relevant when delivery origins from some external mail infrastructure outside of Google.


How is this site grabbing my mobile number? I came across a site that is able to know all the information about my mobile phone including my telephone number, what network I'm on and much more. It only works if people visit the site via the phones Internet Browser what is installed on every phone. So don't use a browser you would have downloaded such as Chrome or Firefox. So for example for people with the new Samsung if you click App and then the Samsung folder and then click Internet that is your standard internet browser.

If you visit OffersAlerts.com using your standard mobile browser and also make sure you load the page using your mobile data and not via WiFi. You will see if you look at the URL that the site now has grabbed your information.

I thought this was no longer possible to do in the UK? How are they doing this? I understand its all based off the headers used and grabbing the MSISDN but i thought this was no longer possible?

Is this site doing something illegal/dodgy? Is it the standard internet browsers that are allowing our information to be leaked since it doesn't work on browsers like Chrome?

Have I stumbled up on something which should be reported?

Extended HTTP headers are propagated by your mobile operator, at their discretion, as described in Detect an MSISDN (mobile number) with the browser.

They won't work when you are on Wi-Fi, or if you are browsing on a secure HTTPS connection. But otherwise, your mobile operator is free to add or not add any of the HTTP x-headers, based on the browser you are using, page you are visiting, your contract (or lack of) with that operator, and any other info they may find relevant. Often, the operators only pass these headers for their own 'mobile portal'.

None of these headers should be trusted by the backend, they all can be easily spoofed.

A long list of such headers, caught in the wild, may be found here: https://mobiforge.com/design-development/useful-x-headers.

You can use a simple service at http://www.mulliner.org/pc.cgi that shows you all information that external web sites receive from your phone.


How could an attacker MITM an average Joe? Before HSTS, any attacker could simply use SSLStrip and other such methods to "Rogue AP" and read data over the network from people in say coffee shops and the like?

How vulnerable is an average Joe in 2016 vulnerable to a MitM attack?

Let's assume that we are only talking about websites which uses HSTS, and that he keeps his system relatively updated (3 months old software give or take). Vulnerabilities in phone apps or the kernel, etc. can be mentioned. Would Joe be in any significant danger by just logging in to his bank or his PayPal?

The most common MitM vectors are any kind of shared network. This can range from using your neighbor's WiFi (here they, or at least their router, are automatically in a MitM position), to leaving your WiFi open (enables an attacker to connect and do ARP spoofing), to using public networks at coffee shops, airports, hotels, schools, etc. (the owner has automatic MitM; others on the network can use ARP spoofing), to business/workplace networks (your admin has MitM, others may or may not be able to gain it).

Accidentally connecting to malicious networks is also a risk. It's very easy to set up a "fake" access point (using a PC) that has an arbitrary SSID and password; if your laptop/tablet/phone is set to automatically connect to a known network, and the attacker can spoof that network (like, maybe it's the one at your favorite coffee shop, even though you're not there right now), then the attacker can use that to get a MitM position when your device connects automatically. Most people let their devices connect automatically to any network they've seen before (and some even connect to popular networks that they haven't seen before), which puts them at risk from such attacks.

HOWEVER, all the threats mentioned so far are pretty minimal as long as HSTS is used (or the app avoids ever using insecure HTTP). There are still some risks. For example, Heartbleed could be used against clients even if the server was patched, assuming the attacker had a MitM position, and some TLS clients are still vulnerable to it because people are bad at pushing updates to old software. In general, though, it's hard to effectively attack somebody this way.

Finally, though, there's the risk of interference at the ISP or backbone level. Many countries restrict the Internet within their borders, and in some cases this is done via a MitM position. Such threats are among the most dangerous, as a nation-state (especially) can simply procure fraudulent certificates that almost any device will trust, enabling interception of TLS traffic (unless good cert pinning is used).

Even without that, though, it's not that rare for CAs to issue TLS certificates to untrusted entities. It's not common, but it happens. Additionally, attacks (such as arbitrary file reads) against web servers can be used to steal their TLS private keys, enabling attackers to successfully spoof those servers. Based on my experience, that's a pretty common class of vulnerability. Such stolen certificates will not only get past HSTS, they'll also pass certificate pinning. There is no perfect defense.


How to test email spoofing with this php script? I want to harden my SPF setting.

However I have trouble testing my SPF setting.

I want to be able send a test email to try out my new SPF settings.

Most of the resource on internet seems to be use a similar php script, which looks something like this:

<?php
$to      = 'nobody@example.com';
$subject = 'the subject';
$message = 'hello';
$headers = 'From: webmaster@example.com' . "\r\n";
mail($to, $subject, $message, $headers);
?>

(The above comes from the website here: https://dylan.tweney.com/2017/10/25/how-to-fake-an-email-from-almost-anyone-in-under-5-minutes/)

I am not familiar with php at all. When I run it on my macbookpro, it throws this error:

Parse error: syntax error, unexpected '$subject' (T_VARIABLE) in /Users/antkong/myproject/_test_mail/test.php on line 5

Here is the command: php -n -f test.php

and the version of my php run time is

$ php -version
PHP 7.1.23 (cli) (built: Feb 22 2019 22:19:32) ( NTS )
Copyright (c) 1997-2018 The PHP Group
Zend Engine v3.1.0, Copyright (c) 1998-2018 Zend Technologies

My questions:

What do I need to run this php script successfully?
I don't need to stick to php. I am happy to use other language such as python. I wonder if there is a counterpart of the php script above written in python or other language which is easier to set up and run?

There's nothing wrong with your code there. What you're getting is a code compile error, and your code is syntactically fine.

I'm running your code just dumping the variables rather than trying to send an email:

<?php
$to      = 'nobody@example.com';
$subject = 'the subject';
$message = 'hello';
$headers = 'From: webmaster@example.com' . "\r\n";
var_dump($to, $subject, $message, $headers);
?>

Which outputs:

string(18) "nobody@example.com"
string(11) "the subject"
string(5) "hello"
string(29) "From: webmaster@example.com
"

I can make a similar error appear by removing one of the semicolons from the code as such:

<?php
$to      = 'nobody@example.com' //removed semicolon here
$subject = 'the subject';
$message = 'hello';
$headers = 'From: webmaster@example.com' . "\r\n";
var_dump($to, $subject, $message, $headers);
?>

Which outputs:

Parse error: syntax error, unexpected '$subject' (T_VARIABLE) in F:\test.php on line 3

Which even in itself is different from the "error in line 5" you're getting. My suggestion is that you're not running the code you think you are. Double check test.php and go from there.


Make server return "Unable to split netmask from target expression" I'm interested in making my website a lot more secure and, while playing about scanning other websites, I found that one website responds to nmap traceroute, curl and wget console commands in such a manner that it returns the following response:

Unable to split netmask from target expression

However, the URL itself works fine when accessed from any browser, including via anonymous or pseudo-anonymous internet browsers (like TOR). I would be interested in replicating similar behavior for my website/server.

Can anyone tell me how to do this and what it is exactly that's causing this particular server behaviour?

You are entering a URL with / in it rather than a hostname, and the tools you're using are treating that as a CIDR address (and then failing to parse it).

Compare the following (wrong way, right way):

$ nmap http://www.example.com/

Starting Nmap 6.40 ( http://nmap.org ) at 2016-08-11 10:10 EDT
Unable to split netmask from target expression: "http://www.example.com/"
WARNING: No targets were specified, so 0 hosts scanned.
Nmap done: 0 IP addresses (0 hosts up) scanned in 0.04 seconds

$ nmap www.example.com

Starting Nmap 6.40 ( http://nmap.org ) at 2016-08-11 10:10 EDT
Nmap scan report for www.example.com (172.31.43.14)
Host is up (0.062s latency).
rDNS record for 172.31.43.14: www.example.com
Not shown: 994 closed ports
PORT    STATE SERVICE
22/tcp  open  ssh
25/tcp  open  smtp
80/tcp  open  http
443/tcp open  https
587/tcp open  submission
993/tcp open  imaps

Nmap done: 1 IP address (1 host up) scanned in 1.03 seconds
$


metasploit exploits and payloads documentation Where can i found the documentation of the exploits and payloads available in metasploit.

I am looking for a documentation that tells what does the exploit or the payload do, and possibly a description and how it works.

When you select a module such as exploit or payload in msfconsole, type the info command and it is going to show you the description of the module detailing what the module does. You can get the same information on the rapid7's online module pages as well.

An example (taken from Offensive Security's Metasploit Unleashed is given below:

msf  exploit(ms09_050_smb2_negotiate_func_index) > info

       Name: Microsoft SRV2.SYS SMB Negotiate ProcessID Function Table Dereference
     Module: exploit/windows/smb/ms09_050_smb2_negotiate_func_index
    Version: 14774
   Platform: Windows
 Privileged: Yes
    License: Metasploit Framework License (BSD)
       Rank: Good

Provided by:
  Laurent Gaffie <laurent.gaffie@gmail.com>
  hdm <hdm@metasploit.com>
  sf <stephen_fewer@harmonysecurity.com>

Available targets:
  Id  Name
  --  ----
  0   Windows Vista SP1/SP2 and Server 2008 (x86)

Basic options:
  Name   Current Setting  Required  Description
  ----   ---------------  --------  -----------
  RHOST                   yes       The target address
  RPORT  445              yes       The target port
  WAIT   180              yes       The number of seconds to wait for the attack to complete.

Payload information:
  Space: 1024

Description:
  This module exploits an out of bounds function table dereference in
  the SMB request validation code of the SRV2.SYS driver included with
  Windows Vista, Windows 7 release candidates (not RTM), and Windows
  2008 Server prior to R2. Windows Vista without SP1 does not seem
  affected by this flaw.

References:
  http://www.microsoft.com/technet/security/bulletin/MS09-050.mspx
  http://cve.mitre.org/cgi-bin/cvename.cgi?name=2009-3103
  http://www.securityfocus.com/bid/36299
  http://www.osvdb.org/57799
  http://seclists.org/fulldisclosure/2009/Sep/0039.html
  http://www.microsoft.com/technet/security/Bulletin/MS09-050.mspx

msf  exploit(ms09_050_smb2_negotiate_func_index) >

Update: Lately, Metasploit has started adding documentation to each of the module submitted and for the ones already included in the framework. These are available in the documentation directory under the same path as that of the exploit. For example, the documentation for the exploit module exploit/windows/smb/ms08_067_netapi can be found at documentation/exploit/windows/smb/ms08_067_netapi.md.


Asymmetric key encryption that can have a public decryption key, but encryption key cannot be computed from that Is there a way where I can distribute a public decryption key, but the encryption key cannot be computed from that key, so that anyone who reads one of my encrypted message, he/she can be quite sure that it was originally written by me?

So basically it is the traditional asymmetric encryption-decryption scheme, but in reverse.

First of all, as @WhiteWinterWolf points out, this is a digital signature scheme. Digital signing is specifically for the purpose of making sure that the message is from you, not somebody else, and hasn't been modified since it was signed. Without going into the math, here's how it works:

You have a message that you want the world to know came from you
You have a public/private key pair that supports signing (RSA, DSA, etc.)
You take a cryptographic hash (usually something like SHA-256) of the message
 - Like asymmetric encryption, signing schemes work best on small bits of data
You create a digital signature of the hash digest (the output of the hash function)
 - This requires your private key
You distribute the message, the signature, and the algorithms (hash and signing) used
Alice has your public key, and wants to confirm that the message is authentic
Alice re-hashes the message, with the same scheme
Alice then uses your public key to turn the signature back into the hash digest
Alice checks if the digest of the message and the digest from the signature match
 - This is called verifying a signature

Cryptographic signatures are used all over. They're used in X.509 certificates (like SSL/TLS uses) to verify that the certificate was issued by a trusted authority, and hasn't been tampered with. They're used in secure email, to make sure that the recipient knows the sender of the mail wasn't spoofed. They're used with signed files, usually executable binaries, so that the author of the file is known. That's just a few of the common uses.

Now, with that said, let's be clear about something:

Encryption, in general, does NOT provide authentication (proof of the identity of the source of the message) or integrity (confirmation that the message has not been tampered with); only confidentiality (also called privacy or secrecy). If you encrypt a message, but don't sign it (or provide some other form of verification), an attacker can take the encrypted message and manipulate it, changing the meaning even though the attacker doesn't know what the original text was. The recipient of the message can then decrypt the message, and may have no idea it was tampered with.

For some stuff, this isn't very meaningful; an attacker tweaking English text that they don't know the content of will produce meaningless gibberish. For other things, though, it can matter a lot. Do not rely on encryption to verify where a message comes from! (Caveat: if using an "authenticated encryption" scheme, that includes integrity checks and, if nobody else has the key, also provides authentication. You shouldn't assume that encryption provides these things, though; most of the time it doesn't.)


How can you tell what certificate parameters were used with openssl? So for example, Chrome browser (using F12 > security) will tell you what key-exchange, cipher, and protocol was used by a website's SSL certificate.

e.g.

protocol (TLS 1.2), a strong key exchange (ECDHE_RSA with P-256), and a strong cipher (AES_256_GCM).

Is there a way to tell if your own certificate is generated via what algorithm and key-exchange in linux? Using e.g. openssl?

I ask because I wasn't the IT guy from the hosting company who created the private key which was then used to send a CSR to our CA and gotten it signed.

I just want to know if he generated it correctly. I have the .csr, .pem files. I can ask, but I wanna know if there's a way to inspect.

... will tell you what key-exchange, cipher, and protocol was used by a website's SSL certificate.

This is wrong. Key exchange method, cipher and protocol are features of the TLS connection and not the certificate. In fact, these parameters are (mostly) independent of the certificate. They depend instead on the capabilities and configurations of the TLS stack in client and server.

The relevant features of the certificate are instead the type and the strength of the key (i.e. RSA-2048, ...), the issuing CA, and the signature algorithm used to sign the certificate (i.e. SHA-256, SHA-1, ...)

  I have the .csr, .pem files. I can ask, but I wanna know if there's a way to inspect.

openssl req -text will show you (among other things) the information about the public key for the CSR, while openssl x509  -text will show you additionally the issuer which signed the certificate and the signature algorithm used.

You don't know from this if the admin used the proper openssl commands to generate the CSR. You don't even know if if he used openssl at all or instead some other tools. You can only see the result.

In the worst case the certificate were generated by using a weak random generator and are thus insecure, like in the case of the Debian random generator bug.  But you will not be able to detect any broken random generator just from looking at the single certificate. And you also don't know how well your hosting provider protects the private key just from looking at the CSR or certificate.


Does SNI reveal the virtualhost during the CONNECT query to a HTTPS proxy? Also, the name of the actual virtualhost is going through unencrypted or not?

The raw answer to your question is: yes, SNI reveals the target host name to the proxy. But, to be more complete:

As @Steffen indicates, the CONNECT method usually works with host names. The client could ask for a connection with a target IP address, or another host name which happens to resolve (through the DNS) to the same IP address, but clients don't usually do that.
Once the connection is established, the proxy is supposed to forward all data bytes back and forth, which implies, in particular, that the proxy sees all the bytes. If SNI is used, then the ClientHello handshake message from the client will contain the target server host name.

One may note, in particular, that a proxy could "delay" the sending. As per the RFC, when the proxy answers to the CONNECT request, it is supposed to have already talked to the target server; but a slightly cheating proxy could claim that the server was contacted, and wait for the client's ClientHello message to do the actual connection. This (theoretically) allows for dispatching requests to different actual servers depending on the target host name.
In any case, the server will answer with handshake messages of its own, including its Certificate. This is sent, necessarily, prior to any encryption taking place. The server's certificate will contain the server's name (the client verifies it) so, regardless of SNI, the server's name cannot be considered a well-preserved secret.

What is encrypted is whatever is sent after the handshake, i.e. the HTTP headers. But all the proxy stuff happens before, and the SSL handshake itself contains unencrypted data.

Now maybe your question is about situations where the connection to the proxy uses SSL, and the enemy is an eavesdropper between the client and the proxy, not the proxy itself. In that case, the enemy won't see the target host name. The enemy will see the SSL handshake, with SNI, between the client and the proxy, and SNI will show the proxy name at that level. Once the tunnel is established, anything that occurs between client and proxy is quite opaque to the adversary (though he will still be able to make a good guess about the size of the data exchanges).

As was pointed out, DNS requests may be revealing. A typical client will first need to resolve the target name to decide whether it is a "local" or "non-local" server, the latter being handled through the proxy. Thus, chances are that the client will first shout the target server name, unencrypted and out of any SSL context. It is probably possible to configure proxying so that such leaks do not occur, but it can take some effort. A more comprehensive proxying solution (VPN, SOCK proxy over SSH...) may be more effective at hiding the names of the sites you browse from your coworkers / fellow students / whatever.


Logout tied to cookie expiry I am looking for an event to automatically logout a user from the application. Typically I would do it when an inactive session expires. I was wondering if it is secure to do so using cookies. So here are my questions,

Is it secure to have logout algorithm tied cookie expiry?
Can the expiry date/time of the cookie be manipulated by the client?
If manipulation is possible does it hold true for "secure" cookies (Secure / HttpOnly flag set)

Session state within an application should ideally be managed server-side from a security perspective.

So in terms of expiry a list of active sessions should be stored and they should be removed from the server after an agreed period of inactivity (exactly what this would be depends on the application sensitivity, user base etc)

The application should also offer an explicit logout facility which terminates the users session server-side.

If you rely on a client-side measures (e.g. cookie expiry) there is always the risk that an attacker will get access to a cookie and replay it after the expiry has passed.  If your application is unable to tell whether that cookie should still be valid then this may expose it to unauthorised access.

In this case the use of cookie flags (e.g. secure, httpOnly) may reduce the risks of an attacker compromising a user's session token, but don't remove the central issue that the server can't tell whether the cookie should still be valid or not.

It is possible to handle session expiry without holding state on the server by using cookies which are protected from tampering and store the expiry date/time within them (e.g. ASP.NETs default session management) but this suffers from the weakness of making it hard to allow users to explicitly terminate the session prior to the time stored in the cookie.


Email header field "From" : angle brackets + square brackets I received a spam and the field "From" looks like this (I have anonymized the field):

John Doe <john.doe@company.com> John Doe [mailto:data@firewall.tz]

How this field has been built? The information in bold corresponds
to what?
Which rule can I implement to block it? Example: If an email
address between square brackets is indicated AND it doesn't    match
the email address indicated between angle bracket then refuse    the
email?

I suppose that the "true" email of the sender is data@firewall.tz but usually only the two first pieces of information are showed in the field "From" (the display name and the <email address>).

If it was straightforward to create a rule to block this, then every client would do it - the problem is legitimate mail re-senders, like constantcontact, mailchimp, etc. would be blocked, too. Even tech support departments use this technique.

In short, you could do it, but you probably wouldn't want to.


There was a potential harmful file on my server, What damage has it done? I received an abuse complaint for my server from hosting provider. After a thorough search I found file with name "title.php" in a WordPress installation's upload directory.

I am curious to know what kind of damage it may have done to my server/website?

http://pastebin.com/r7CdCizX

It is clearly a spamming component. There's lots of mail sending functions around the code:

private function mailPassthru($to, $subject, $body, $header, $params) {

public function isSMTP()

public function isMail()

public function isSendmail()

public function isQmail()

This generally occurs when you have an outdated Wordpress installation laying around. There are lots of bots out there scanning for vulnerable Wordpress and its plugins.

You should disinfect your installation. This and this will provide some pointers to follow.

After cleaning and reinstalling, keep watching the Wordpress dashboard for updates, and update everything as soon as there is a new version available. Otherwise you will be infected again.


How can I know if an attack is still valid, if there is no CVE for it? I found a PoC for a MitM-attack towards RDP published in March 2017 but no CVE in any of the databases and no mention of a patch by Microsoft.

I want to know if this still works, how would I find out without testing it myself?

The issue described in the paper is not an actual vulnerability, but rather the consequence of using untrusted certificates in the environment. When connecting to a remote RDP server, it uses by default a self-signed certificate. When you accept that certificate, you trust the remote system. If this is the way in your network, then attacker can set up a proxy server and proxy all your RDP traffic through his system, e.g. perform a man-in-the-middle attack. It starts when you accept attacker’s certificate and establish the connection.

To avoid this issue, you need to use trusted certificates, signed by trusted CA. And when the remote server offers an untrusted certificate, you should suspect that something is wrong. It is the same issue as with web browsers and fake certificates.

The bottom line, if your organization is using self-signed certificates, it is vulnerable to this attack.

Here are some articles on how to configure your RDP servers to use trusted certificates:
https://blogs.technet.microsoft.com/enterprisemobility/2010/04/09/configuring-remote-desktop-certificates/

https://www.derekseaman.com/2013/01/creating-custom-remote-desktop-services.html


Certificate based authentication vs Username and Password authentication What are the advantages and drawbacks of the certificate based authentication over username and password authentication?
I know some, but I would appreciate a structured and detailed answer.

UPDATE

I am interested as well in knowing what attacks are they prone to, e.g. as so far mentioned brute force, while nothing is mentioned for certificates... what about XSRF? A certificate is expected to have shorter lifetime and be able to be revoked while a password would live longer before an admin policy ask to change it...

1. Users are dumb

A password is something that fits in the memory of a user, and the user chooses it. Since authentication is about verifying the user physical identity remotely (from the point of view of the verifier), the user behavior is necessarily involved in the process -- however, passwords rely on the part of the user which is most notoriously mediocre at handling security, namely his brain. Users simply do not grasp what password entropy is about. I am not blaming them for that: this is a technical subject, a specialization, which cannot realistically become "common sense" any time soon. On the other hand, security of a physical token is much more "tangible" and average users can become quite good at it. Evolutionists would tell that humans have been positively selected for that for the last million years, because those who could not hold to their flint tools did not survive enough to have offspring.

Hollywood movies can be used as a model of how users think about passwords -- if only because those users go to movies, too. Invariably, the Arch Enemy has a short password and just loves to brag about it and distributes clues whenever he can. And, invariably, a British Secret Agent guesses the password in time to deactivate the fusion bomb which was planted under the Queen's favorite flower bed. Movies project a distorted, exaggerated reality, but they still represent the mental baseline on which average users operate: they envision passwords as providing security through being more "witty" than the attacker. And, invariably, most fail at it.

"Password strength" can be somewhat improved by mandatory rules (at least eight characters, at least two digits, at least one uppercase and one lowercase letter...) but those rules are seen as a burden by the users, and sometimes as an insufferable constraint on their innate freedom -- so the users become to fight the rules, with great creativity, beginning with the traditional writing down of password on a stick-up note. More often than not, password strengthening rules backfire that way.

On the other hand, user certificates imply a storage system, and if that system is a physical device that the user carries around with his house or car keys, then security relies (in part) on how well the average user manages the security of a physical object, and they usually do a good job at it. At least better than when it comes to choosing good password. So that's a big advantage of certificates.

2. Certificates use asymmetric cryptography

The "asymmetry" is about separating roles. With a password, whoever verifies the password knows at some point the password or a password-equivalent data (well, that's not entirely true in the case of PAKE protocols). With user certificates, the certificate is issued by a certification authority, who guarantees the link between a physical identity and a cryptographic public key. The verifier may be a distinct entity, and can verify such a link and use it to authenticate the user, without getting the ability to impersonate the user.

In a nutshell, this is the point of certificates: to separate those who define the user digital identity (i.e. the entity which does the mapping from the physical identity to the computer world) from those who authenticate users.

This opens the road to digital signatures which bring non-repudiation. This particularly interests banks which take financial orders from online customers: they need to authenticate customers (that's money we are talking about, a very serious matter) but they would love to have a convincing trace of the orders -- in the sense of: a judge would be convinced. With mere authentication, the bank gains some assurance that it is talking to the right customer, but it cannot prove it to third parties; the bank could build a fake connection transcript, so it is weaponless against a customer who claims to be framed by the bank itself. Digital signatures are not immediately available even if the user has a certificate; but if the user can use a certificate for authentication then most of the hard work has been done.

Also, passwords are inherently vulnerable to phishing attacks, whereas user certificates are not. Precisely because of asymmetry: the certificate usage never involves revealing any secret data to the peer, so an attacker impersonating the server cannot learn anything of value that way.

3. Certificates are complex

Deploying user certificates is complex, thus expensive:

Issuing and managing certificates is a full can of worm, as any PKI vendor can tell you (and, indeed, I do tell you). Especially the revocation management. PKI is about 5% cryptography and 95% procedures. It can be done, but not cheaply.
User certificates imply that users store their private key in some way, under their "exclusive access". This is done either in software (existing operating systems and/or Web browsers can do that) or using dedicated hardware, but both solutions have their own set of usability issues. The two main problems which will arise are 1) the user loses his key, and 2) an attacker obtains a copy of the key. Software storage makes key loss a plausible issue (at the mercy of a failed hard disk), and sharing the key between several systems (e.g. a desktop computer and an iPad) implies some manual operations which are unlikely to be well protected against attackers. Hardware tokens imply the whole messy business of device drivers, which may be even worse.
A user certificate implies relatively complex mathematical operations on the client side; this is not a problem for even an anemic Pentium II, but you will not be able to use certificates from some Javascript slapped within a generic Web site. Certificate requires active cooperation from client-side software, and said software tends to be, let's say, ergonomically suboptimal in that matter. Average users can normally learn to use client certificates for a HTTPS connection to a Web site, but at the cost of learning how to ignore the occasional warning popup, which makes them much more vulnerable to some attacks (e.g. active attacks where the attacker tries to feed them its own fake server certificate).

On the other hand, password-based authentication is really easy to integrate just about everywhere. It is equally easy to mess up, of course; but at least it does not necessarily involve some incompressible extra costs.

Summary

User certificates allow for a separation of roles which passwords cannot do. They do so at the expense of adding a horde of implementation and deployment issues, which make them expensive. However, passwords remain cheap by fitting in a human mind, which inherently implies low security. Security issues with passwords can be somewhat mitigated by some trickeries (up to an including PAKE protocols) and, most of all, by blaming the user in case of a problem (we know the average user cannot choose a secure password, but any mishap will still be his fault -- that's how banks do it).