Heartbleed and Routers/ASAs/other OK, so I first heard about heartbleed a few hours ago through the stack exchange questions feed, and after a moments panic, realised that the only web servers I have secured via OpenSSL are on the internal network. Patched anyway, but now I have been scratching my head on whether or not other services are vulnerable. Specifically I am wondering about Router type devices such as:

Cisco ASA's
DD-WRT routers
NAS's with VPN support

I believe some of these use OpenSSL for things like SSH, point to point or site to site VPN's, the mini web servers they run for admin interface, etc. But I have been batting my head against a wall trying to find the versions running on them. For instance, on our DD-WRT device, I have been unable to even find an OpenSSL command in the filesystem, so maybe I am wrong on them using OpenSSL at all.

I am fairly sure that ASA's running 8.4 are on 0.9.8 and thus safe (but would really like confirmation as, again, I was unable to find this for certain in the ASDM or telnet interfaces), and if that's true I suppose we can assume older versions of ASA will be similarly safe.

Does anyone have any information on these kind of devices?

Edit: I've been reading these meta questions (they're on SO, but I think they may be stack-agnostic, as it were) to try to figure out what the best practise is here, as I think the correct answer may actually be a combination of what's here. That's probably my fault as much as any, because I suppose this is actually a compound question itself. I've considered posting my own answer and accepting it combining the available information about several devices, plus what I found about the exact affected DD-WRT build numbers, but I wonder if that's not kind of rude considering that you guys have supplied most of it and that way I deny EVERYONE the accepted answer rep. I know the accepted practise (from those meta.SO links) seems to be to pick a best one by my own conditions and upvote the rest (the latter of which is done), but different answers here are equally good for different parts of my question. Any thoughts? (Even, should this edit be a meta.sec question of it's own? I hesitate to do that when the question seems to be asked so many times already on other meta's)

I've found a nice post from a Cisco Support Engineer regarding to the ASA:

  However, if you are trying to find the OpenSSL version for an ASA (Adaptive Security Appliance), you can determine this version from the ASA release notes.  Simply examine the "Open Source" notes that are located in the release notes of the particular ASA image you are concerned with.  For example, from the ASA 8.4 release notes, you will find a section titled "Related Documentation", which has a link that points to "ASA Series Documentation".  From there, you will find a link for "Open Source License".  That will take you to an "Open Source" page which reveals that the OpenSSL version that runs on the ASA 8.4 code is "0.9.8f"

Due to this neither 8.4(x) nor 9.1(x) are vulnerable as they are using parts of the OpenSSL version 0.9.8f


Crazy Finished Message in TLS I've tried to understand the content of the Finished Message of TLS. I'm using wireshark to capture the traffic between my browser and the internet. I noticed a "stangeness" when the chosen ciphersuite is AES_GCM. Beign it a stream-cipher, it has no padding, so, if I got it right, the data being sent in the Finished Message is:

8 bytes Explicit Nonce
12 bytes verify_data
16 bytes authentication tag

That is, 36 bytes in total. The "problem" is that the Finished Message packet size is 40 bytes.

And here it is:

Why the message packet is 40 bytes and what are the red bytes?

And why wireshark sees two hello requests?

And another this... the Client answers with a 176 bytes packet:

What am I missing?

Each handshake message has a header, which contains its type (as a handshake message) and length. This header is in addition to the record header. See section 7.4 for a description of the header: one byte for the message type, and three bytes for the message length.

In the case of the Finished message, the header should be 14 00 00 0C (in hexadecimal), with 0x14 meaning "Finished" and 00 00 0C encoding the message contents length (12 bytes). Therefore, what is encrypted with GCM is actually 16 bytes, not 12. GCM adds the 8-byte explicit nonce (which is combined with the 4-byte implicit nonce, yielding the 12-byte nonce that raw GCM actually needs), and the 16-byte authentication tag, for a grand total of 40 bytes, as you observe.

Of course, this record is encrypted, so you don't see its contents; in particular, Wireshark will not show the handshake message header. All it knows from the record header is that the record contains "some handshake data".

As for your second question, it is possible that the client is not content with the handshake and wants to start a new one, immediately sending a ClientHello just after the Finished. Two handshake messages can be merged into a single "handshake" record.


Is it dangerous to call spam phone numbers, even if you know they're spammers? I sometimes like to check spam just to see how the messages look like, and I found someone who actually put an American phone number (1-XXX-XXX-XXXX). Most of these spammers are either trying to get money out of you, or hack you in ways like disguising as services like Google+.

Not that I actually want to, but I am curious if calling the number would do something to my phone. How could a hacker possibly access sensitive information just by tricking someone into calling. I have heard (no idea where), that some numbers when called, will charge you an enormous bill. Could this be true?

Can you get "hacked" by calling a number?

  I am curious if calling the number would do something to my phone. How could a hacker possibly access sensitive information just by tricking someone into calling.

It could be a hack, or it could be a prelude to a hack. Here are some rough examples:

If you call them, the spammer can find out if that phone number is owned by an actual person. The spammer can also easily fake the same area code as you, and set up a clever social engineering trick that may involve you thinking with the wrong head.
If you're dumb enough to call them, you may be gullible enough to fork over additional information. If you're dumb enough, they may call you from other numbers, or forward you to another number.
There may also be an exploit in your phone's processing of various messages/content types. While they could easily target all phones at once by using some form of auto-messaging feature, this may be easily stopped by carriers.

Learning more about you allows an attacker to guess secret answers, passwords, etc. If you're the gullible type, chances are you don't have a good password policy, or you could be tricked into visiting a malicious website, or both.

But why not just send infected videos or pictures to everyone?

Let's assume the spammer has developed, or found, a program that helps with automatically dialing phone numbers.

If they're sending an infected video or picture to multiple recipients, they may quickly run out of data. It's far cheaper and easier to target people individually, especially those gullible enough to call the number.

In fact, if they target everyone, then that also increases the chance of their scam becoming well-known. By limiting their attacks only to the gullible, they've found a very good way to limit detection and knowledge of their particular scam.

The reason why they'd want to limit knowledge is that many folks may be searching for a particular scam, not exactly their specific scam. This is a problem with many gullible people: they can't really think outside the box, and not realize it's the same type of scam, but with different features.

Your information helps scammers engage in Social Engineering tactics

Have you ever tried to contact customer service for anything important, such as banks, online game accounts, websites, etc? Usually, they need specific information from you, or someone pretending to be you, in order to handle your request.

In fact, just recently, I was able to social-engineer a customer service representative for an account of mine by providing details on things I knew about me, without actually providing any real concrete details, or even providing my identity. All I needed was a few bits of information about myself.

Social Engineering is a tactic used everywhere, and often results in  astounding success because people in general are ill-equipped to handle it. If a spammer has your phone number, then it may be possible for them to get other information. Maybe your phone number is tied to different accounts.

Maybe they have a partial database of credentials stolen from various websites, which could include more information on you. Maybe that database includes information on your email address, which will allow the scammer to continue their campaign of phishing without you realizing it.

Can calling spam numbers cost me money?

  I have heard (no idea where), that some numbers when called, will charge you an enormous bill. Could this be true?

Yes, this is possible.

If you're calling a premium-rate telephone number, then that could cost you a lot of money when you call them. If you text a number associated with a "donation", whether it's legitimate or a scam, your phone bill will likely include additional charges.


How can I prevent keys loaded into ssh-agent from being sent to a particular (insecure) server? A particular server I need to interact with has an ancient or crippled sshd installed, and only supports SHA1 algorithms for key exchange. From information in the Snowden documents, I am leery that keys exchanged with servers with weak key exchange algorithms may be intercepted.

I keep a separate identity that I use with only with this server, and have a specific ~/.ssh/config entry to use that identity when connecting; and my machine-wide ssh_config does not permit the insecure key exchange algorithms.

However, if I have added my regular key to ssh-agent, it appears that my hopefully-more-secure key will still get sent over the potentially insecure key exchange.

Is there some way to further secure my configuration, so that I can prevent a key that I want to keep safe and private from being transmitted with a leaky key exchange algorithm?

If not, should there be? It seems that part of the agent contract is "all of these key exchange algorithms are absolutely 100% secure, so its ok to send any key." Since the key exchange algorithms are not all secure, this is (is it?) a problem.

While key exchange algorithms can be locked down at the machine level, this does not always work in practice, and its pretty easy to accidentally/intentionally override this in per-user config. Is there (or again, should there be) a way to configure "identity XYZ may only be used with KexAlgorithms/Ciphers/MACs?"

Gory Details:

I have an rsa identity id_insecure that I want to use with the insecure server, and an ed25519 identity id_secure that I use by default.

To avoid some potentially weak key exchange algorithms, my /etc/ssh_config contains:

Host *
    KexAlgorithms curve25519-sha256@libssh.org,diffie-hellman-group-exchange-sha256

To allow access to the insecure server, since they cannot agree on a key exchange algorithm with the above setting, my ~/.ssh/config contains:

Host insecure_server
    IdentityFile path_to/id_insecure
    KexAlgorithms diffie-helmann-group14-sha1,and-some-other-icky-sha1-algorithms

However, if I load up id_secure into my SSH agent, and ssh -vvv insecure_server, the output will contain

debug1: Offering ED25519 public key: path_to/id_secure
debug3: send_pubkey_test
debug2: we sent a publickey packet, wait for reply
debug1: Authentications that can continue: ...

My understanding is that I have just sent my id_secure identity using the diffie-helmann-group14-sha1 key exchange algorithm, which is not as secure as once thought. If I'm mistaken about what is being passed around... I'd also find that to be valuable information.

You have several misconceptions here.

First, the whole point of a public/private keypair is that you don't send the private key to the server. The only thing your key is used for is signing messages; the server doesn't get your private key at any point during the SSH protocol. Even if you use agent forwarding (which lets you login to other servers from the first one using your key), the server doesn't get your private key: it just passes things on to ssh-agent on your computer, which signs them and sends the signature back to the first server to send on down the line.

Second, "key exchange" in this context doesn't mean "pass around keys," it means "establish a shared secret." The way Diffie-Hellman works is that the client and the server work out a new key, which is completely unrelated to any keys they might have had before. Long-term keys (i.e. the keypairs that are stored in files) are just used to sign elements of the key exchange, so that you know you're talking to the server you think you're talking to.

Third, key exchange in SSH has nothing at all to do with client keys (id_rsa and similar). The server authenticates itself during key exchange using the host key, but client authentication doesn't happen during key exchange. All a client key is used for is to sign a particular string after the key exchange (and after you've sent the username you want to log in to), in order to prove you can sign things with a private key corresponding to an authorized public key for that user. Key exchange algorithms have nothing to do with client keys.

So, weak key exchange doesn't pose any problems at all for private key security. That security doesn't rely on strong key exchange. The only attack you could do is exploit agent forwarding, but that could only work if a) you enabled it in the first place and b) you're still connected (disconnecting = no more agent forwarding).

Fourth, I'm actually not aware of an issue with using SHA-1 for the exchange hash. SHA-1 is weak to collision attacks, which means it's easier than it should be to create two things that hash to the same value. But to successfully MITM the connection, you'd need a second preimage attack, which means creating a collision with something that you don't control. In a collision attack you control both halves of the collision, which is a problem if you're signing something and the attacker can control what you're signing, in which case the attacker could create a colliding pair, get you to sign one thing, and use that as a signature of the other thing. While it's generally better to move away from it, calling it insecure for cases that only need second-preimage resistance is a bit of a stretch.


Changing Structure of SAM database to disable LM usage SAM database normally holds LM and NTLM hashes of local computer.  Recently we applied configurations for disabling NTLMv1 usage in enterprise network . After that we mitigated LM hash usage on SMB and other communications. My question could be dumb but I want to know: If attacker got SAM database contents somehow ( via live OS, mimikatz and so on) , will that configuration help us to disable LM hash exposure or not?  what is recommended to configure endpoints in a way that it only store NTLM hash?

It is not recommended to change SAM file and it is not reasonable to make modifications on it. If you have physical access to machine, nothing will help you to stop adversary. LM and NTLM hash types must be inside SAM, by disabling LM hash exchange during communications is enough to stop "some kind of" hijack and cracking techniques but It will not disable or change SAM structure.


What type of authentication should I use, basic or digest? I know that it is strongly recommended to use both basic and digest authentification with https. Many say that if you use SSL, there are no advandages in using digest auth, and basic auth is safe enough. So, for more security, should I use basic authentication with SSL or digest authentication with SSL?

Basic authentication - is login and password encoded by BASE64 function. Almost same as if you transfer tham in plain-text.

Digest - based on md5 function. It's will not give password to leak.

Allways prefer to use Digest over Basic authentification

Liks:

https://en.wikipedia.org/wiki/Basic_access_authentication
https://en.wikipedia.org/wiki/Digest_access_authentication


How can I demonstrate that 3 independent root CAs validated my domain? I am concerned about the hacking of a root CA and want to buy 3 SSL certs from completely different providers who will independently validate my identity.  Then at presentation time, I will send all 3 "certifications" to the client.

What approaches exist to accommodate this need from either a protocol perspective, or crypto (where the keys are joined in some way)?

Context

An existing HTTP web client, chrome extension, or SOCKS/Proxy that does additional validation
A proof of concept for another implementation not yet invented (e.g. a new version of TLS incorporating new encryption)

The possible solutions I've thought of include:

Client makes 3 HTTPS requests, where each request is encrypted with a different certificate.  The response should be a random number that is equal in all 3 responses.
2 keys are signed and contain a x509 custom field that references the serial number of the "validated" certificate
The keys are mathematically combined in an interesting way that reduces the multiple requests into a single request. (RSA or ECC/Subgroups)

Question

Does such a protocol exist in draft form anywhere?
Is there a way to mathematically combine the validation of N certificates without losing security?

a. I'm interested in crypto that authenticates me 3x as a web host

b. Increases the integrity of the data with a 3x signed data stream

c. Increases the privacy of the data with 3x the encryption

(Note I know DANE might satisfy part of this requirement, but I'm looking for a non DANE / HTS solution)

There is no standard way to do what you envision and I'm not aware of any proposals of relevance. The currently established PKI structure allows only for a single certificate chain (i.e. a single issuer for a certificate) and the TLS protocol like used allows only for a single leaf certificate. In theory one might create a certificate with multiple issuers using certificate extensions and in theory one could extend the validation process in TLS to check for multiple issuers. But again I'm not aware of any serious proposals in this area.
Serving different certificates via multiple HTTPS requests needs also some kind of extensions or hacks, because the server needs to know which of the certificates it needs to send. With new TLS extensions the client could ask for a specific certificate. Without the client might re-use existing extensions like SNI for a different purpose, i.e. give slightly different target host names. Or one could provide different IP addresses in the DNS and each IP address servers a different certificate. Or one could randomly rotate certificates. In all these cases the client has to be aware that it should try to get multiple certificates and how much certificates it should get and how to combine the information. This means some knowledge is needed about the server which is either coded into each certificate (i.e. certificate extension) or which the client got from the external resource in a secure way.
Because there is no standard or even proposed standard to do this you either need to invent your own or try to get the best from the current standards. Since hacking of a root CA is your main concern you might be already protected enough with the existing standard HPKP, i.e. certificate pinning on first use. This way no compromised CA can create a usable certificate in your name which gets accepted by browsers which visited you already, because the attacker would need your private key to misuse the certificate. And if HPKP is not enough you could apply for your public key to be included in the browser as it gets shipped. And this public key pinning is not restricted to a specific CA but only to your key pair, which means the key and thus the HPKP information stay the same if you use the same key in another certificate signed by a different CA. Thus you can easily change CA if one gets distrusted by the browser. Not all browsers currently support HPKP but it gets better. So this is probably the best you could get without trying to establish yet another standard or create a little used browser extension. If HPKP is not an option for you the you might add the reasons for this to your question.


All 4 WP sites hosted in A2 Hosting were hacked The hack redirects all my sites to another site

All are running WP 5.4.1 (latest) and I even have a site that barely runs any plugins, just a simple open-source theme with 3 common plugins - Contact Form 7, etc.

Thus, can I assume the attacker might be coming from A2 Hosting?

I moved one of my sites to a new host (InMotion Hosting) and left 2 running in A2 Hosting. I deleted another site. So, far both sites left in A2 hosting got hacked again (4th time). I did change cPanel password after 3rd hack. The InMotion site is safe. I did not delete any of my files or changed them. I just restored from old backup that I did at A2.

As you said, it is possible that the server is vulnerable, so if your hosting plan is on shared hosting then it's the hosting provider's fault, and your websites are alright. However it's not easy to be sure about that. Here's a list of things I would consider:

Type of hosting. Is it shared hosting? Then you only need to make sure your home directory is clean, change every password (WP, cPanel, FTP, etc.), and check every setting in the hosting panel (like suspicious additional FTP accounts, etc.). But what if your hosting is an unmanaged VPS? Then it'd be a problem, you'd have to check everything, because you run the whole server (and you'd better nuke it from orbit).
Check every file. Supposing you are on shared hosting and you only need to check your home directory, you need to make sure every file is clean. Restoring from a backup might not be enough, because... are you really sure the backup is clean? One way to check if WP is clean is to download its original files (same version as yours), and compare them with your installation (with diff -rq for example). You can do the same for themes and plugins.
Check the database. This is hard. I don't know of a decent way to do this yet. There are probably some scanners available, specific for WP. Otherwise you need to check at least there aren't suspicious users with privileges in the user table. Then try to check if there is any JavaScript injected in posts, comments, etc. Something like grep -i 'script' might help, but it might not be enough and it might have too many false positives. As I said, I believe checking the DB is hard.
Contact the hosting provider. If you are pretty sure your website is ok, then the infection might come from a vulnerability on the server, which is run by the hosting provider.


TLS-Handshake, Server Key Exchange, Diffie-Hellman: Where does key length come from? Where does the key length come from?

In this example it is 2048 bits long:

Secure Sockets Layer
    TLSv1.2 Record Layer: Handshake Protocol: Server Key Exchange
        Content Type: Handshake (22)
        Version: TLS 1.2 (0x0303)
        Length: 783
        Handshake Protocol: Server Key Exchange
            Handshake Type: Server Key Exchange (12)
            Length: 779
            Diffie-Hellman Server Params
                p Length: 256
                p: ...
                g Length: 1
                g: 02
                Pubkey Length: 256
                Pubkey: ...
                Signature Algorithm: rsa_pkcs1_sha512 (0x0601)
                Signature Length: 256
                Signature: ...

It is apparently not a parameter of the cyper suite (here: TLS_DHE_RSA_WITH_AES_128_GCM_SHA256) as there is no key length given for DHE.

Is this just a parameter configured on the server side? Or is it somehow negotiated? I cannot find much information except in "Bulletproof SSL and TLS" in the section about deployment best practices.

  To be on the safe side, if deploying DHE, configure it with at least
  2,048 bits of security.

That section makes it sound like it's server configuration...

Reason for my question:

I have got a piece of older software which cannot connect to a server via TLS. It complains that it only supports DH key lengths from 512 to 2048. And in the according network trace p Length is 512 (== 4096 bits). Thus the TLS handshake fails.

Now I need to know how I could get my legacy software (running on an embedded device) to talk to the server (preferrably without updating the software).

For TLS through 1.2 in most cases (see below) using DHE key exchange, the DH group (prime p and generator g of suitable subgroup of Z_p^*) is sent by the server; the client has no influence beyond specifying a list of ciphersuites that does or does not lead the server to select a ciphersuite that uses DHE (at all).

In general server software (or firmware, or middleware as applicable) varies in how it determines the DHE group to use. Some servers are hardcoded, and some are configurable; if configurable the method of configuration and options available vary wildly. However, it would be pretty aggressive for a server today to hardcode 4096-bit DH, so I'd say it's reasonably likely this server is configurable somehow.

Since you give no clue what the server is, it is impossible to give any useful answer as to that 'how'. Although if it is any of the more common ones like Apache httd, nginx, haproxy, or Tomcat (including Jboss/Wildfly/whatever it is today) you can probably find documentation and/or existing Qs here or superuser.com or serverfault.com or maybe unix.SX by searching something like "{server [version]} configure DH".

Technically there is an extension to TLS1.2 (and earlier), RFC7919 which does allow the client and server to negotiate among a standardized (specifically, IANA-registered) set of groups. But I'd be surprised if a client that can't support DH over 2048 bits supports RFC7919. You can confirm this by looking at the extensions in the ClientHello message in your capture. TLS1.3 uses only the RFC7919 groups for DHE, within its substantially new scheme for doing keyexchange, but you aren't using 1.3.

Depending on what other ciphersuites the client offers, it might be possible to configure or otherwise induce the server to choose a non-DHE ciphersuite; in that case there's no issue of the server using DHE parameters the client dislikes. Especially if both client and server support any ECDHE ciphersuite(s) with acceptable other parameters (auth and data cipher/MAC), that would provide the same forward-secrecy benefit as DHE but be more likely to interoperate successfully since for ECDHE (pre-1.3) practically everybody implemented the former Suite B curves P-256 and P-384, and maybe P-521.


What are methods against code leakage for web applications? I like to see the server-side web application layer as independent as possible, from the OS, from the server software like (Apache, nginx, IIS, et cetera). In order to easily grab the application and deploy it on a newer system. That has advantages as well as risks.

In the example I will use a setup with Apache and PHP. When the new underlying OS or server software isn't configured properly (that's indeed another problem), the programming language, for example PHP might not be interpreted as code but as text. Therefor if all the source-code is in a public folder (and the file-folder structure is known), the source-code leaks. Several solutions come to mind:

move all (except one) PHP file(s) out of the public folder so that if it happens only one file (with includes only) is leaked and not the whole source-code;
detect if the underlying system such as Apache supports PHP, for example in .htaccess (since that ships with the application) and deny access to everything when PHP isn't supported/enabled. I once asked a question about that here: https://stackoverflow.com/questions/39450760/how-to-check-in-htaccess-if-php-is-enabled.

Such methods are easy to use and improve the concept of layered security. Since if the underlying layer fails, the application can still fallback in it's own deny state. Preventing in this case source-code leakage.

I like to know if there are other methods for the purpose of preventing source-code leakage. For example in a web-application firewall or proxy that detects source-code patterns or different practical configuration approaches.

Your first solution is the correct one - have an entrypoint file which doesn't contain anything confidential but bootstraps the environment for the app and loads the code from a location unreachable by the web server - in fact that's how pretty much all web frameworks do it - PHP is the only one (to my knowledge) that persists with this stupid idea of putting the code in the web root folder and letting the web server handle URL routing.


In what cases people know that I see their stories on instagram or mystalk? I don't have an instagram account, but I always look to my friends' profiles on instagram or mystalk and see their stories.
BTW my google account is always signed in when I check their stories on instagram or mystalk. So my question is: in what cases they will know that I see their stories? For example, can they know (from my google account) that it is me?

In what cases they will know that I see their stories? For example, can they know (from my google account) that it is me?

Assuming with 'they', you mean your friends, it is highly unlikely they will know it was you unless they would know your IP address and use some sort of analytics to see who visited and from where.
It used to be possible for websites to determine whether a user is logged in to their Google account or not. I do not know if this still is the case, but this was the only information that was possible to gather from Google.


Validating an SSL certificate chain according to RFC 5280: Am I understanding this correctly? we're in the process of replacing certificates with SHA1 hash due to Google's move to let them appear less secure in Chrome. The replacement certificates use a different intermediate CA than the ones we're currently using, but the same root CA. During testing we noticed that our SSL clients would fail to validate the chain using the new certificates we don't quite understand why.

Here's the specifics:

Currently the chain the server sends looks like this:

Root CA, signed by Server CA X from the same authority (came with Server Certificate)
Intermediate CA 1 (came with Server Certificate)
Server Certificate

in our SSL clients we trust:

Root CA, self signed, but same CN and same key (same skid)! (Downloaded from authority; same as Mozilla incorporates in its products)
Intermediate CA 1 (identical with the one the server sends)

This works with the current certificate chain but only because we trust Intermediate CA 1. If we remove this it fails because Server CA X is not trusted. New certificates obviously don't work then, because they are signed by a different intermediate CA.

Now, from reading RFC 5280, section 6.1, my impression is that our SSL client does not adhere to standards, because from what I've read my understanding of a certificate path validation is this (simplified):

start with the trust anchor; validate if it's still currently valid (time) etc.
for the following certificates: check if the CN and key of the previous certificate match with the issuers CN and key of the current certificate (and check pathlen constrains etc...)
the last certificate must not be a CA certificate

The point is: Our SSL client fails to validate the chain because the root certificate it's configured to use as a trust anchor has a different issuer than the root certificate presented by the server. However, CN and key are identical for both. From my understanding of what I've read in RFC 5280 the SSL client should not care for the issuer of its trust anchor. There are also no policies defined in the certificates inside the chain that would enforce anything like that. However, I don't know if our SSL client may enforce additional policies that would lead to this (not my system).

So my question is: Does our SSL client behave correctly in this scenario or not? And of course: Why?

Thanks in advance

Edit: I know that the server should only send the intermediate CA cert and not the root cert, however, we're using what the authority provided as a cabundle alongside the certificate, which included the root certificate. Moreover, from what I know, the client should disregard the root certificate sent by the server in that case.

Also what's weird is that the client behaves as if it validates the chain from the server certificate down to something it can trust and then stops, whereas the specs say it should validate the chain from the trust anchor up to the server certificate.

Edit2: The different "versions" of the Root CA cert all have the same SKID - they only differ in issuer and serial number (of course).

Also, just came to mind, from the first edit's information it seems the SSL client either needs the root certificate in trust and chain to be identical in its issuer and possibly serial number to accept it.

There is X.509, and there is SSL/TLS. TLS expects the server to send an X.509 certificate chain, from which the client will extract the server's public key. Then things diverge:

In pure X.509, the server should send its certificate for the client to validate; possibly, the server may add an unordered bunch of extra certificates that could prove useful to the client, basically some possibly relevant intermediate CA. The client would still be free to validate the certificate in any way as it sees fit, in particular through arbitrary chain building. This method is demonstrated in, for instance, in CMS (formerly known as "PKCS#7"), in which a signed document (SignedData) references the signer's certificate and optionally includes an unordered set (ASN.1 "SET") of extra certificates.
In SSL/TLS, things don't go that way. Instead, the server should send the exact chain that is to be used; the server is explicitly allowed to omit the root CA, but that's all. Any client is entitled (at least historically, if not de jure) to reject the server's certificate if the chain does not match this pattern. Of course, any client is allowed to make an effort and try to validate the server's certificate in the X.509 way, with its own path building; but there are SSL client out there that do not make such an effort.

A relevant excerpt of RFC 5246 is in appendix F.1.1:

  If the server is authenticated,
     its certificate message must provide a valid certificate chain
     leading to an acceptable certificate authority.

This is the passage that gives SSL clients the "right" to unceremoniously reject server chains that cannot be validated "as is".

In your case, the chain sent by the server is:

    Root-X -> CA1 -> Server

where "Root-X" is "the root signed by Server CA X". The lazy client tries to validate that chain twice:

First attempt is based on the assumption that the chain includes the root CA. The client does not find "Root-X" in the list of its own root CA, so this fails.
Second attempt is based on the assumption that the chain does not include the root CA. The client scans its root CA for an issuer for Root-X (and that's the critical point). It does not find any, hence failure.

In order to validate the chain sent by your server, the client must be slightly less lazy, and try to find an issuer for CA1 within its own set of trusted CA. This would require a third assumption, namely that the chain sent by the server does include a root CA, but not "the right one".

I suppose that your failing SSL client is a "lazy client" as enunciated above. To make sure, try to connect with Internet Explorer as client; IE, for all its shortcomings, is not lazy when it comes to certificate validation. IE will try to rebuild a chain from the certificates sent by the server, the certificates it has in its own stores, and the certificates it can download. Notably, any certificate may contain a URL pointing to the certificate for its issuer (that's part of the Authority Information Access extension); IE (and, in fact, Windows in general) will gleefully follow such URL and gather intermediate CA (HTTP-only, not HTTPS, to avoid a nasty loop).

If you can thus confirm that the problem is indeed a lazy client, then possible workarounds include the following:

Change the chain sent by the server so that it includes the self-signed root, or simply ends at CA1.
Install the "Server CA X" certificate as trusted CA in the clients.
Modify/configure the client so as not to be lazy.

Of course it is quite possible that your chain is incorrect in some other way, which is difficult to assess without actually seeing the certificates. The path validation algorithm is complex, so there might be another extension that does not please the client (e.g. one certificate might be using a Name Constraints extension on which the SSL client implementation just chokes). Possibly, the client is not lazy, but insists on ascertaining revocation status of all certificates in the path, and some CRL or OCSP responder is out-of-date or unreachable. There are hundreds of ways by which certificate validation may fail.


Root CA with Extended Key Usage fields I recently started using AWS's Certificate Manager to get free TLS certificates for my load balancer. When I was inspecting the certificate chain I noticed that the Root CA, Starfield Class 2 Certification Authority, has the following extended key usage values:

SSL client
SSL server
Netscape SSL server
S/MIME signing
S/MIME encryption
CRL signing
Any Purpose
OCSP helper
Time Stamp signing

I then opened up the Trusted Root Certification Authorities store on a Windows laptop I have and started looking at several of the root CAs. It turns out that a lot of them have the same or very similar EKU values.  I understand why CRL and OCSP are present (even though I would imagine the root would be kept offline which would make OCSP a bit more difficult), but why the others? Does this mean that the CA, in addition to issuing certificates, can also sign code, perform S/MIME functionality, etc.? Or does the presence of these values mean that certificates that descend from this root CA can only be used for, at most, those EKU values?

I briefly skimmed the Extended Key Usage section of RFC 5280 and the only thing I saw on the topic was this:

  In general, this extension will appear only in end entity certificates.

To summarize my questions:

Does placing these EKU values in the root CA cert indicate that the end-entity certificates descending from that root can have, at most, those EKU values?
If no to 1, why are these values present in multiple root CAs? Is it so these CAs can also be used for those purposes? If so, why would one want to do that instead of issuing an end-entity certificate with those EKUs?

The reason you see that ExtendedKeyUsage list is simply down to the application used by the website linked in your question to dump the textual representation of the certificate.

If you look at the page again you will see a Base-64 encoded representation of the certificate.  Copy and paste it into a file and save it. Dump the textual representation of the certificate with OpenSSL and you'll simply see the following.

Note: If you are running Windows, save it with a .cer or .crt extension and double-click on it.  Windows will display the certificate in a GUI, showing similar information.

$ openssl x509 -noout -text -in StarField.cer
Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number: 0 (0x0)
    Signature Algorithm: sha1WithRSAEncryption
        Issuer: C=US, O=Starfield Technologies, Inc., OU=Starfield Class 2 Certification Authority
        Validity
            Not Before: Jun 29 17:39:16 2004 GMT
            Not After : Jun 29 17:39:16 2034 GMT
        Subject: C=US, O=Starfield Technologies, Inc., OU=Starfield Class 2 Certification Authority
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
                Public-Key: (2048 bit)
                Modulus:
                    00:b7:32:c8:fe:e9:71:a6:04:85:ad:0c:11:64:df:
                    ce:4d:ef:c8:03:18:87:3f:a1:ab:fb:3c:a6:9f:f0:
                    c3:a1:da:d4:d8:6e:2b:53:90:fb:24:a4:3e:84:f0:
                    9e:e8:5f:ec:e5:27:44:f5:28:a6:3f:7b:de:e0:2a:
                    f0:c8:af:53:2f:9e:ca:05:01:93:1e:8f:66:1c:39:
                    a7:4d:fa:5a:b6:73:04:25:66:eb:77:7f:e7:59:c6:
                    4a:99:25:14:54:eb:26:c7:f3:7f:19:d5:30:70:8f:
                    af:b0:46:2a:ff:ad:eb:29:ed:d7:9f:aa:04:87:a3:
                    d4:f9:89:a5:34:5f:db:43:91:82:36:d9:66:3c:b1:
                    b8:b9:82:fd:9c:3a:3e:10:c8:3b:ef:06:65:66:7a:
                    9b:19:18:3d:ff:71:51:3c:30:2e:5f:be:3d:77:73:
                    b2:5d:06:6c:c3:23:56:9a:2b:85:26:92:1c:a7:02:
                    b3:e4:3f:0d:af:08:79:82:b8:36:3d:ea:9c:d3:35:
                    b3:bc:69:ca:f5:cc:9d:e8:fd:64:8d:17:80:33:6e:
                    5e:4a:5d:99:c9:1e:87:b4:9d:1a:c0:d5:6e:13:35:
                    23:5e:df:9b:5f:3d:ef:d6:f7:76:c2:ea:3e:bb:78:
                    0d:1c:42:67:6b:04:d8:f8:d6:da:6f:8b:f2:44:a0:
                    01:ab
                Exponent: 3 (0x3)
        X509v3 extensions:
            X509v3 Subject Key Identifier:
                BF:5F:B7:D1:CE:DD:1F:86:F4:5B:55:AC:DC:D7:10:C2:0E:A9:88:E7
            X509v3 Authority Key Identifier:
                keyid:BF:5F:B7:D1:CE:DD:1F:86:F4:5B:55:AC:DC:D7:10:C2:0E:A9:88:E7
                DirName:/C=US/O=Starfield Technologies, Inc./OU=Starfield Class 2 Certification Authority
                serial:00

            X509v3 Basic Constraints:
                CA:TRUE
    Signature Algorithm: sha1WithRSAEncryption
         05:9d:3f:88:9d:d1:c9:1a:55:a1:ac:69:f3:f3:59:da:9b:01:
         87:1a:4f:57:a9:a1:79:09:2a:db:f7:2f:b2:1e:cc:c7:5e:6a:
         d8:83:87:a1:97:ef:49:35:3e:77:06:41:58:62:bf:8e:58:b8:
         0a:67:3f:ec:b3:dd:21:66:1f:c9:54:fa:72:cc:3d:4c:40:d8:
         81:af:77:9e:83:7a:bb:a2:c7:f5:34:17:8e:d9:11:40:f4:fc:
         2c:2a:4d:15:7f:a7:62:5d:2e:25:d3:00:0b:20:1a:1d:68:f9:
         17:b8:f4:bd:8b:ed:28:59:dd:4d:16:8b:17:83:c8:b2:65:c7:
         2d:7a:a5:aa:bc:53:86:6d:dd:57:a4:ca:f8:20:41:0b:68:f0:
         f4:fb:74:be:56:5d:7a:79:f5:f9:1d:85:e3:2d:95:be:f5:71:
         90:43:cc:8d:1f:9a:00:0a:87:29:e9:55:22:58:00:23:ea:e3:
         12:43:29:5b:47:08:dd:8c:41:6a:65:06:a8:e5:21:aa:41:b4:
         95:21:95:b9:7d:d1:34:ab:13:d6:ad:bc:dc:e2:3d:39:cd:bd:
         3e:75:70:a1:18:59:03:c9:22:b4:8f:9c:d5:5e:2a:d7:a5:b6:
         d4:0a:6d:f8:b7:40:11:46:9a:1f:79:0e:62:bf:0f:97:ec:e0:
         2f:1f:17:94

This is what should be expected - no KeyUsage or ExtendedKeyUsage

A root CA certificate shouldn't really contain any extensions (other than optionally SubjectKeyUsage and AuthorityKeyUsage used to help chain building) as it limits what the certificate can be used for during the whole of its long lifetime.  Such limitations should be added at the subordinate CA level.

As you stated in your question, the  ExtendedKeyUsage is for the particular certificate, not for the chain (unlike policy and name constraints).


Experience with a recent DDoS attack on Apache I originally posted a question here since I was not familiar with an actual distributed denial of service attack (DDoS) on my server. I noticed that my server is very slow in responding to HTTP requests whereas HTTPS requests are fairly good (not as good as expected though).

By doing a bit of analysis and looking at the dmesg and the growing size of apache's error.log (over 5GB), I found out that hey I'm receiving a DDoS attack.
I shutdown Apache and did a netstat, I found out that all the SYN flood is gone.

In summary:

The problem was that remote servers were initiation requests to Apache on port 80 and would leave the tcp connection open and thus exhausting Apache's resources.

What I did:

I checked if I had any Apache updates, but I was up to date.

To make sure that my server did not run a bot to communicate with a command and control server, I replaced the current volume image with a very old one at the time I did not have any problems. As soon as I started the server, I received the attacks as before, so this wasn't an issue.

I installed CSF, although I was hesitated because I could not initially trust this software. After starting CSF's SYN flood prevention, I noticed some improvement on HTTP requests but not much.

What I finally did was to change the IP of the server and the attack was gone. By the way, iptables rules were not that effective, because I ended up blocking legitimate traffic.

What's still a question for me:

Why HTTPS requests were being handled in a timely manner?
Why servers are still easily vulnerable to such attacks despite tons of research in this area?
How can I prevent this problem in future?

Requests to port 443 were likely faster because you were being DDoSed on port 80.  Apache preforks processes.  To service port 80, Apache needed to spawn a new process.  To service 443, Apache was using an existing process. (I think...  must check later)
DDoS mitigation is still a hard problem.  You need to discern legit traffic from fake traffic, and you need to do it with as little interaction as possible.
If this is a for-profit service, a professional web server admin and/or a DDoS mitigation service would be the way to go.

If you are a web server admin, then digging into the features of the tools e.g., CSF and Apache mod_security can help.  Attackers are focused on trying to look like legit traffic.  I'm an admin myself and this kind of attack is a serious PITA to protect against.  Getting a handle on the signature of the traffic and filtering appropriately can take time.  Fortunately, today, the DDoS tools don't respond quickly, so they'll move on to the next target or just give up for a while.

Note that there is a lot of sorta-legit traffic which looks like DoS attacks.  Badly behaved spiders are the most annoying to me.  People linking graphics into social media can look like a DDoS, with dozens or hundreds of hits per second (from unique IPs) if somebody deep links a graphic on a popular forum.

Be sure when you block somebody with IPTables, don't "reject" their traffic.  Drop it.  It slows things down.

I look forward to reading other responses on this topic.


Categorizing CVE product name I'm looking for a way to categorize CVE product names by operating system, application etc. Is there any dataset available to deal with this? https://www.cvedetails.com offers these categories for products but I need this information available offline. Can anyone provide any insight?

Since CVE is only the IDentifier to any vendor-recognized vulnerability for specific software/hardware, there is no way to categorize them using these identifiers as a basis, unless you take into account the year included in the CVE. Although, the year does not always match the date on which the Vulnerability has become public.

Knowing that each CVE ID is related to a Common Platform Enumeration (CPE), you can use it to categorize the CVE. For this, I recommend using the Data Feeds (https://nvd.nist.gov/vuln/data-feeds) provided by National Vulnerability Database (NVD).

I would like to emphasize 2 things:

A CVE can be refused even that the vulnerability comes to
public. In NVD Data Feeds files they appears as "** REJECT **". So, keep these files up-to-date;
You are still at risk for some false negative - i.e. Whose vulnerability affects certain platforms, you find the platform being enumerated in the vendor's security advisory, but it is not being enumerated in the NVD data files: CVE-2017-11779

NVD Data Feeds: https://nvd.nist.gov/vuln/detail/CVE-2017-11779

Portal MS Security Response Center: https://portal.msrc.microsoft.com/en-US/security-guidance/advisory/CVE-2017-11779

Note that the Windows Server 2012's CPE (cpe:/o:microsoft:windows_server_2012) is not present in either NVD Data Feeds nor CVEDetails.


Why did this particular input work for SQL injection? I'm studying infosec, starting to make my way through some of the online wargames out there. Have recently been working on Natas by OverTheWire (http://overthewire.org/wargames/natas/) and it's been great fun so far. My question is related to one of the challenges in the game.

** SPOILERS FOR THE GAME FOLLOW **

On one of the levels, I am given my first encounter with mysql. The backend code looks like this (the game lets you see the php code for each function, at least at the start):

<?
if(array_key_exists("username", $_REQUEST)) {
$link = mysql_connect('localhost', 'natas14', '<censored>');
mysql_select_db('natas14', $link);

$query = "SELECT * from users where username=\"".$_REQUEST["username"]."\" and password=\"".$_REQUEST["password"]."\"";
if(array_key_exists("debug", $_GET)) {
    echo "Executing query: $query
";
}

if(mysql_num_rows(mysql_query($query, $link)) > 0) {
        echo "Successful login! The password for natas15 is <censored>
";
} else {
        echo "Access denied!
";
}

mysql_close($link);
} else {
?>

<form action="index.php" method="POST">
Username: <input name="username">

Password: <input name="password">

<input type="submit" value="Login" />
</form>
<? } ?>

I began researching sql injection, and tried some basic things like foo OR 1=1 as input, but got nothing. I looked at the code and tried inserting quotes with my input, which would throw me errors when I had an odd number of quotes in the input, but didn't know where to go from there.

I eventually started working through the OWASP page about testing for sql injection, and during testing their examples, I came across something which said to try:

$username = 1' or '1' = '1
$password = 1' or '1' = '1

That didn't work, but for some reason, my intuition said to change the first ' to " in the $username input, and the last ' to " in the $password input. So it became

$username = 1" or '1' = '1
$password = 1' or '1' = "1`

And... it worked. satisfied the condition for this block

if(mysql_num_rows(mysql_query($query, $link)) > 0) {
    echo "Successful login! The password for natas15 is <censored>
";
} else {
    echo "Access denied!
";
}

and gave me the password for the next level.

My question is... WHY? I don't know enough about sql injection as I'm obviously a noob, but I don't get what exactly is happening on the sql server with that particular input.

To reiterate, the query looks like this (I used the debug feature in the code above to get it to print the query):

Executing query: SELECT * from users where username="1" or '1' = '1" and password="1' or '1' = "1"`

What is the behavior of this query, and how is sql evaluating it to give me a TRUE output on both inputs (at least I assume that's what it's doing...)? Whenever I change the " to ' in any other configuration within the query, it fails. And the fact that there are an odd number of " and ' within the query is driving me crazy.

Any advice or explanations would be greatly appreciated. I feel like I won't have truly passed this level until I understand what is happening!

Whenever I change the " to ' in any other configuration within the query, it fails.

That would be:

SELECT * from users where
    username = "1' or '1' = '1"
and
    password = "1' or '1' = '1"

This fails because you're literally querying for a user called 1' or '1' = '1 with a password 1' or '1' = '1. If you want to escape from double quotes, you need to use double quotes yourself - as you did. This is your successful query reformatted:

SELECT * from users where
    username = "1"
or
    '1' = '1" and password="1'
or
    '1' = "1"

Since '1' == "1", this evaluates to true.

  And the fact that there are an odd number of " and ' within the query is driving me crazy.

There isn't actually an imbalance of quotes. In particular, '1" and password="1' is one single-quoted string which just happens to have spaces and double quotes inside.


Does incognito mode prevent cookie-theft attacks? A fresh incognito browser will not have access to any cookies
An active session however, will surely save cookies somewhere so I don't have to login to gmail every time I access gmail.com in the same web-browser session
My question is: does incognito mode prevent 100% of cookie-stealing methods of identify fraud

Assumptions
I'm assuming that since you've indicated incognito mode, that you are not talking about attacks where an actor has code running on your machine or remote access.
Background
Cookies are stored on your computer and linked to a specific website that has requested them.  When you get a cookie from gmail at login, it will be presented to gmail on every subsequent request from that browser session and (as you correctly identified) would not be presented to gmail if you were in incognito.    However, you don't need to be in incognito for your cookie from gmail to be kept secrete from any other website.
Exploits
For an exploit to get a cookie from your browser that doesn't belong to it, you'd have to break the sandbox. This could get you access to cookies that were not intended for the website.  Since each tab/window of chrome are separate processes, you do get more isolation by using incognito.
Answer

does incognito mode prevent 100% of cookie-stealing methods of identify fraud

No, there is nothing you can do to prevent anything 100%.  There is no such thing as being "Secure" only "More Secure".  If someone hits you with a browser escape and a privilege escalation, they can do anything they want on your machine including stealing your cookies.


How can I tell which process is generating SYN traffic to localhost? In Wireshark, on the loopback interface, I can see SYN requests from localhost to closed ports on localhost that are being responded to with RST, ACKS.

I'm curious what's generating the traffic. How can I find out?

I can't use netstat because the connections aren't held open. lsof -i :[port-range] doesn't show any results either.

The problem with tools like netstat, ss and lsof is that these work on snapshots of the network state. Connections that are reset during the setup will not show up with high probability.

While Wireshark can capture the TCP packets, it will not be able to tell the process ID that was responsible for it. This information is not provided in a normal Ethernet capture. There is a different mechanism (NFLOG) that can log packets as seen by Netfilter (iptables), but this may at most contain the User ID of the process that generated a packet.

One approach to tackle the issue is by stalling or completely dropping network traffic.

Using Wireshark, you could for example determine that the port range is within 5037-5585.
Add a new firewall rule that drops newly initiated TCP traffic to the loopback interface for that port range:

sudo iptables -I INPUT -p tcp -i lo --dport 5037:5585 --syn -j DROP

Now you can use netstat, ss, etc. to find the offending program. For example:

sudo ss -tapn | grep '5[0-5]'

When done, remove the firewall rule again such that new connections can occur:

sudo iptables -D INPUT -p tcp -i lo --dport 5037:5585 --syn -j DROP

I used this approach to identify that the ADB daemon was trying to connect all the time to some local ports, presumably to locate an Android simulator.


Can people get my social media from my IP address? Is it possible to get say, my snapchat account, from my IP address? I'm slightly worried because I wasn't using a proxy and this (presumably a) guy threatened to post my 'IP and snapchat' to a forum, but I never gave my snapchat. I'm not worried about my IP giving my location because I know the location(s) it gives are wrong, but I'm worried if they got my snapchat.

No, Your ISP can find your social media profiles by using your IP address and timestamp simply by searching into your browsing history in their logs.

So that attacker can't find anything about you with your IP address only. Maybe if he has more details like your name, he could use some services like pipl.com to search your social media profiles. That's a process called "Doxing" but that's not our topic here and it's not that effective without the right information!

No need to worry!


How to change the browser canvas html hash for fingerprinting? building on this previous post Can canvas hash be used to track me and ruin my anonymity?

I want to ask:

Is there any way a user can affect this canvas html hash generation, a way to make the hash change regularly? Could things like playing around with browser settings or cookie policies help? What good methods are there?

Or one step further: is there a method to globally disable the canvas hash generation?

A hash needs input. So if we know what parameters are included in the "input" data which are then hashed, we could play around with those input parameters, correct? Do you know where to find the input data list which flows into the canvas hash generation? timezone, system language, etc. those are inputs, and if you just change one single input, the resulting canvas hash should be totally different right? This is the function of a hash after all - to deliver random strings if input changes...

I think you've misunderstood what the canvas hash is.  The "canvas" is a JS component that allows the browser to draw graphics.

The hash input is only a single thing, the binary data that makes up the image drawn by your graphics card.

Obviously, a number of things go into the generation of that image.  There are multiple JS engines used by different browsers, which will affect the generation as well as the version of the engine (and of the code running on the engine).  Additionally your graphics drivers, the GPU and/or CPU will all have an affect.

However, none of that (besides switching browsers) is easy to change on a regular basis.

The good news is that their are a limited amount of combinations of these things.  I'd imagine something like the newest Chrome, on Windows with an Intel CPU and integrated GPU is likely to be the most common combination.

As was said in your previous question, that is only a single element of the fingerprint built up to uniquely identify you.  This website gives you a good idea of how unique (or not) you are.


Vulnerability of the open port I'm installing service on the cloud machine and I was wondering on port vulnerabilities for my customers.

My service which lives on server A (often on a customer site) needs to access server B (lives in a cloud) through port 1234. On server B there's a service running on port 1234, but customer often wants to block access to it as non standard port. Server A doesn't have a service running on that port, but still needs to be able to communicate on it.

Is there a vulnerability of opening port, which is used to establish connection with another service? If you scan a machine A, the port would be open, but there's nothing running on it.

Typical solution would be enabling port 1234 between IP A and IP B, but in cloud, we can't guarantee the IP addresses.

An open port is not a security vulnerability in itself. It allows an attacker to connect and exploit any vulnerabilities in the process that's running.

The answer to your question depends on how sure you are in security of your service. Did you ask someone to look at the code? Does it run with limited privileges (not root?). What's the worst that can happen if someone can control this service from the Internet?

Given answers to these questions ("risks"), you need to balance them with benefits from setting it up as you describe and see what you and your customers are comfortable with.


How to retrieve the admin's password of a webapp? I'm doing a pentesting example on a web app and I have dumped all the database.

I have a table with the users in plaintext and the passwords hashed.

I have to find the admin's password (I know that it's possible because that is the example's final goal). But admin's password is hashed and cannot be reverse with any lookup table.

Could you please list all the ways via I could login as the admin? That is, what are the many ways I could find the admin's password?

There is a file upload vulnerability because I am able to upload a .php file, but calling system calls via PHP is avoided: "Unable to fork ecc..." so I don't think that uploading a shell is the way. But I will listen to all your suggestions.

The web server is IIS 7.5 and the DBMS is MySQL. Assume that there is no salt.

I hope I'm clear.

Thanks in advance.

I have to find the admin's password (I know that it's possible because that is the example's final goal). But admin's password is hashed and cannot be reverse with any lookup table.

You can, however, find a hash collision that computes to the same value.  Will it take a long time?  Yes, but the amount of time may or may not be feasible, depending on the hashing algorithm used.

  Could you please list all the ways via I could login as the admin? That is, what are the many ways I could find the admin's password?

Although they may not seem like it, these are different questions.  For instance, if you find a string that hashes to the same (as described above), you won't have the password, but you'll have a password that works.

A more common approach is session stealing, in which you possess the identifier that is supposed to prove you are a user, but don't have the ability to log in as them once that session expires.  This is fairly trivial to do any time sessions are transmitted over plaintext.

There are many different attacks you could try, but they depend quite a bit on the specific application - if you could do the same thing on every app, we'd just bundle it into a pentesting tool and cut out the person.  It's impossible for us to give you any good advice without knowing the specifics of the app you're trying to break.

And the point of an exercise like this is to learn for yourself, neh?


What unique device fingerprinting information can an iOS 12 or iOS 13 app collect? As a follow-on to these questions:

What unique fingerprinting information can an iOS7 app collect?

What unique device fingerprinting information can an iOS8 app collect?

What unique device fingerprinting information can an iOS9 app collect?

What unique fingerprinting information can an iOS 10 app collect?

What unique device fingerprinting information can an iOS 11 app collect?

Apple Progress since iOS 11:

re: Motion Sensors (accelerometer, gyroscope, magnetometer): "On iOS
12 12.2, Apple adopted our suggestion (§VI) and added random noise to
the ADC outputs. Apple also removed access to motion sensors from
Mobile Safari by default." SENSORID: Sensor Calibration
Fingerprinting for Smartphones It's unclear if Apple removed
access to motion sensors from apps, or if sensors are covered by the
"Motion and Fitness" privacy setting.
In iOS 12, Apple has introduced device fingerprinting protections in
Safari "by only sharing a simplified system profile". However,
it's unclear the extent of these protections, and the extent to which
they carry over to app web views or other app system profile access.

Other Open Questions:

As always there is basic system info available similar to what any
web page can access: IP address, HTTP headers, etc. Many of these are
low entropy or can be changed by the user through various means, but
it may be possible to combine enough for a reasonable identification.
Or for reasonable enough correlation for cross-device tracking.
It appears that apps can only get enhanced information about a Wi-Fi
hotspot with a special entitlement from Apple (it's not clear to the
layperson exactly what information). However, there does appear to be
a way to obtain network name of the current Wi-Fi network, which
is a problem because it can allow location tracking and therefore
also correlations to other people or sensitive places. [See UPDATE below]
What uses exist of persistent data stores by apps, or by apps across
an app group, that survive app (or app group) deletion? Are there any
persistent data stores that survive device erase and restore, that
can be accessed by an app after restore?

Are there any other fingerprinting vectors or open questions?

In general, what remaining device fingerprinting privacy / security vulnerabilities still exist as of iOS 12, particularly those that have no user settings or user actions that can thwart them?

UPDATE: Since it's late in the upgrade cycle, some new WWDC information on iOS 13:

Location access permission will be required to access the Wi-Fi AP
name and MAC address (unless the app is the current VPN or hotspot
app). p.86
User consent is now required for all CoreBluetooth API’s, "to find
and connect to Bluetooth accessories, and allow your device to be
found over Bluetooth." p.43

What uses exist of persistent data stores by apps, or by apps across an app group, that survive app (or app group) deletion

If I understood the question correctly, looks like all app-specific keychain items still survive app uninstall (as confirmed by Apple Staff back in Dec 2017). It changed for a while in iOS 10.3 beta, but reverted back by GM and never disappeared since that time (I could not find any evidence of the otherwise; Apple's article on using keychain for developers still says "you'll want to remove password item from the keychain"; it doesn't says a developer should remove everything nor allow for automatic removal of it by iOS).

Moreover, there don't seem to exist any way for end user to remove such app-specific pieces from iOS local keychain.

On the above link, there's email of Apple Developer Relations to further inquire on this as of iOS 12/13.


Secure information exchange between web applications using browser redirection We're implementing a web application (US) that needs to exchange sensitive information with a third-party web application (THEM). The way we'd like it to work is that an end user clicks a hyperlink, navigates to the third-party web application and magically the sensitive information is available to the third-party web application.

As you'd expect, we'd rather not send that sensitive information along with the url the user clicked. We do not control the third-party web application, but we can impose how they integrate with our web application. We'd like to keep this as simple as possible from a technology perspective (low bar to entry so to speak). Obviously we have full control over our own web application.

We were thinking along the lines of having some sort of one-time usable, randomly generated, restricted in time, access token.

We assume the end-user has been identified/authenticated.
The end-user clicks a link which obtains an access token from our own web application. Since all sensitive information is available server side, there's no need to share it with the end-user's browser. We store the access token and its expiry date and time along with the sensitive information. The sensitive information cannot be derived from the access token itself. Our web application redirects the end-user's browser to the third-party web application with the access token in the redirection url.
The third-party web application receives the incoming request and uses the access token to obtain the sensitive information by issuing a server side request for the information back to our web application. Our web-application returns the sensitive information and now the third-party web application can use said information. Obviously we'll handle access token removal, expiration, etc.

Apart from someone being able to obtain the access token in transit and having to secure the access token storage as well as the server-side communication between our application and the third-party application, do you see any other security holes? Instead of rolling our own is there any widely adopted standard we could use instead?

This is not terribly different than what OAuth is designed to do, if we were to tweak the workflow.

If you were to implement this using OAuth, your application would include an OAuth provider, and the third party would sign up to be an OAuth client.

The user, who is the resource owner, when redirected to the third-party site would simply authorize that site to access their resource (the secret) that your site is keeping safe for them.

The model looks like this:


Bypass with wrong cvv of debit card and getting OTP This is happening in Visa/MasterCard/American Express, etc. I tried checking in many payment apps and payment gateways that if I enter the correct debit card number, name, valid date, and wrong CVV number, I am able to receive OTP. however, the transaction is unsuccessful due to validation at the last for wrong CVV.

But shouldn't it suppose to verify before I get the OTP? What's the reason, Isn' it a security issue?

But shouldn't it suppose verify before I get the OTP? What's the
  reason, Isn' it a security issue?

This is absolutely NOT a security issue! quite the opposite it's a protection.

Lets go through the steps.

You put in card details.
You put in CVV
You put in the OTP.

The payment is processed if and only if the combination of all of it are correct.

Now assume a scenario where it tell's you the CVV is wrong before the 2FA that is just going to simply give the attacker a chance to better attack.Now the attacker knows the CVV is wrong and can simply change that.While in the correct scenario attacker will have to break 2 Factor authentication to gain that information


What does chacha20-poly1305@openssh.com mean for me? OpenSSH just introduced a new protocol, chacha20-poly1305@openssh.com, which combines the two algorithms from DJB: ChaCha20 and Poly1305-AES.  It was inspired by a similar proposal for TLS, which seems to have actively been backed by Google in the recent months.

But most SSH installations are inherently different from TLS.

What does this protocol mean for SSH?   Is it just "a high-performance cipher to replace RC4 since it is pretty close to broken now", to quote the developer, or is it also a great choice to use as the default protocol on, say, new x86 installations, in cases where the crypto use by ssh isn't visibly know to be a bottleneck?  How would this protocol compare to the default crypto that's been in ssh for the past several releases, e.g. ECDSA 256 or RSA 2048?

Two things that it means to me are:

it's a stream cipher, therefore not parallelizable.  Although it's a stream cipher, it has a randomly accessible output stream (PDF), so it can be parallelized (unlike RC4, and stream ciphers in general). Poly1305 is also parallelizable

SSH already has a set of counter mode block ciphers which are parallelizable (RFC4344 Section 4) though they don't get you a performance gain out of the box. ChaCha20 (20 rounds) is a little faster than RC4, comparing cycles per byte, and is faster than AES256.
it's an extra algorithm in the SSH negotiation

The second point needs some elaboration: there have been a number of extra key-exchange (EC), MAC (SHA-2) algorithms added recently, and now another cipher. This increase causes problems with older (including embedded/devices) SSH server implementations. In SSH the various algorithms are spelled out, rather than having short, fixed identifiers like TLS. The workaround is to chop the list down with explicit Ciphers, MACs and/or KexAlgorithms in your ssh config. There's also the potential for protocol enforcing firewalls or IPSs to misfire.

I believe one protocol difference between TLS and SSH is that the authentication, key-exchange, cipher and MAC are identified and negotiated independently, with TLS each publickey-kex-cipher-mac set is one of a defined suite. Poly1305 adds authentication, so ChaCha20-Poly1305 is (effectively) an authenticating stream cipher, no separate MAC is required by SSH for it, the benefit of this is explained in David Miller's article linked to in the question.


Confidentiality and Authenticity of the Key in a Key-Value Store What, if anything, can be used to provide confidentiality and authenticity guarantees for the storage keys used to store data in a key-value store?

To be clear what I mean by the storage keys - I mean the "key" in "key-value" store - I do not mean an encryption key.

The key-value store is something like Amazon S3 and is not trusted.

The storage keys have to be considered to be just as sensitive as the value objects.

But the storage keys are used to retrieve data from the store so they must also have a construction which is repeatable.

I'm using PHP and libsodium (via ParagonIE's Halite) to encrypt the data and ideally I would use the same library to construct the storage keys.

A related question mentions HMAC, but I don't know if that is useful.

Based on the answers given so far, the following could be a good solution:-

use \ParagonIE\Halite\Symmetric\Crypto.authenticate
use \ParagonIE\Halite\Symmetric\Crypto.encrypt
use \ParagonIE\Halite\Symmetric\Crypto.decrypt

// put
map.put(
  authenticate(storage_key, secret_signing_key),
  encrypt(concat(storage_key, value), secret_encryption_key)
)

// get
ciphertext = map.get(
  authenticate(storage_key, secret_signing_key)
)
plaintext = decrypt(ciphertext, secret_encryption_key)
// ensure that the key that was hashed equals the key that was encrypted
assert(equals(storage_key, substring(ciphertext, 0, len(storage_key)))

return substring(ciphertext, len(storage_key)) // just the data

If I understood your goal correctly, consider following.
Since you want to have "confidentiality and authenticity" of the keys, encrypt them. If you choose an encryption method that is not fast enough, consider using something other instead of map keys and store tuple of (original encrypted key, original value). For instance use a hash of the original key or, if this is critical for you from the security point of view, use a KDF key as a map key. So, consider following approaches:

map.put(encrypt(key), value)

map.put(hash(key), tuple[encrypt(key), value])

map.put(argon2(key), tuple[encrypt(key), value])

Of course the map should be able to deal with collisions.


Pentesting an ATM OS upgraded from Windows XP to Windows 7 How to approach penetration testing of a ATM OS that was upgraded from Windows XP to Windows 7? From what I gather, the testing flow should be as follows:

Architectural Review
Pentesting OS and Application
Physical Audit

For the current requirement, I am focusing on the second item. Typically, I'd scan the machine and look for service/port that a specific service is using, then run an application specific exploit. I am planning to follow PCI ATM Security Guidelines (PDF), section 4.2  Security of Basic Software and section 4.4 ATM Application Management.

Could I take a different, faster approach for an ATM whose OS was upgraded from Windows XP to Windows 7, if it was already penetration tested while running Windows XP?

I realise you didn't get an answer here - the reason for this is very simple:

There is no shortcut. You cannot make assumptions from a previous test on XP that there will be weaknesses in the same ATM running Windows 7.

What you should do is conduct your full approach, starting with PCI requirements but adding hardening expectations and best practices for Win 7, as PCI is a very low bar and while you are testing you may as well make it useful.


Is PGP combined with a regular web-based email service secure? With the disappearance of private email services like Lavabit and Tormail (http://www.dailydot.com/news/email-anonymous-hushmail-lavabit-nsa/) it seems that we will need to resort back to standard services like Hotmail and Gmail for email purposes. However, is PGP secure enough to protect the content of a email from prying eyes and possibly government surveilance?

Basically, the path my "secure" email will take is as follows:

Trusted and logless VPN/Proxy - HTTPS - Hotmail/Gmail with PGP - recieving party

Will this setup provide enough protection and anoymity for both parties?

They key to PGP e-mail security is that it provides full end-to-end encryption. The "path" you describe is actually flawed, and in fact may be overkill depending on your needs.

Hopefully, the below overview will help you see how the multiple layers of security you are suggesting would be applied.

You start with your e-mail.

  [Email]

Your system encrypts the e-mail with PGP.

  [PGP [Email] ]

Your system puts the package into a secure stream addressed to your e-mail provider. (We'll say SSL.)

  [SSL [PGP [Email] ] ] ]

Your system sends that traffic to your trusted VPN gateway.

  [VPN [SSL [PGP [Email] ] ] ]

Once traffic reaches the VPN gateway, the VPN gateway forwards it along to your e-mail provider through the open Internet. However, this is not part of your trusted connection to the VPN gateway.

  [SSL [PGP [Email] ] ]

Your e-mail provider stores the message on their servers. Without intimate knowledge or agreements as to how the provider handles their data storage, you cannot assume that any additional encryption is used.

  [PGP [Email] ]

When the E-mail provider receives your message, they send it along to the recipient's e-mail provider. However, you cannot be sure that their provider's servers require connection security to receive e-mail or that there is any encryption used on their at-rest data.

  [PGP [Email] ]

The recipient contacts their provider's server to check their e-mail. However, you cannot be sure that the recipient's client software is configured to use a secure connection for this.

  [PGP [Email] ]

The recipient finally decrypts the e-mail and reads it.

  [Email]

Strictly for the purpose of ensuring confidentiality of the e-mail message's contents, the VPN is essentially superfluous. In fact, so long as PGP remains unbroken and the keys you are using are trustworthy and un-compromised, every layer of security applied afterward could fail and the e-mail's contents would still remain protected in transit. You could be using an unencrypted connection to your e-mail provider over the clear Internet, from the sketchiest of coffee house hotspots, and your e-mail would still be protected in its travels. That's the point of end-to-end encryption - it's made so that the transfer medium does not need to be trusted, especially because it cannot be trusted.

If you're looking to additionally provide anonymity, then the VPN does have a purpose. However, to be fully effective, this requires that you do not provide any Personally Identifiable Information (PII) to your e-mail & VPN providers (E-mail headers still have to be sent in the clear, and you cannot trust the path between your VPN provider and the recipient. Your e-mail and/or VPN provider may therefore be forced by court order or other coercive measures to reveal your account info & connection logs.) and that you do not do anything over the VPN connection from which your PII can be directly obtained or inferred.

Of course, all this protection also relies upon yours and the recipient's systems being secure. If either system is compromised, all bets are off anyway.

In the end, you should always remember Law #9.


How does IP traceback works? In part prompted by the difficulties in determining the true origins
  of DDOS attacks featuring spoofed IP addresses, researchers have
  attempted to develop the concept of IP traceback: determining the
  actual origin of a packet on the Internet, without relying on the IP
  source field contained in that potentially falsified packet. Early IP
  traceback techniques relied on logging each packet forwarded by each
  router.

I know that IP traceback helps trace the real user that send a request by spoofing an IP address. But what information does the router logs?

There is no singular IP Traceback implementation, although researchers have proposed many solutions in the past.

If you look at the Wikipedia article under the "Router based approach" section, you will find a few proposed methods of fingerprinting a packet.

Here's an article from CISCO that touches on techniques routers can perform to prevent IP spoofing.

I'm not aware of any router that has a turnkey solution that performs IP Traceback outside of your own network though. There isn't a standard protocol to request an IP Traceback.


Potential danger of infection through downloading malware? Recently I was on Nox Player's website checking out their Android emulator. I did some googling and came to the conclusion that it was bundled with tons of malware and as a result didn't install it.
In the process, I accidentally clicked on the Windows 10 download link which began to download an .exe file. I immediately cancelled the download and cleared Chrome's cache.
Is it possible to be infected by the malware if you simply downloaded 2 MB of 150MB? For reference, I am using macOS so it isn't even compatible with .exe programs.

Simply, no. If you didn't execute anything, the odds are approaching 0 (especially since it wasn't a MacOS executable).


Passwords: store encrypted, view in plain text I've already asked that question at stackoverflow but i was informed it is a bit too broad and relies more in here instead. So let me just copy and paste what i asked there:

I have a security related dilemma which i'm unable to figure out by myself from my knowledge about web applications security.

Let's say i want to create a service where user can store and VIEW in plain text its passwords for multiple services. In such case we have few things to consider: basic security measures by encrypting stored passwords with hash, how to protect passwords in case if they would have been stolen from database by, for example, dumping the database by attacker.

This means passwords would need to be stored encrypted but being possible to display to a user in plain text. Standard way to store passwords for authentication is to hash them for example with bcrypt or other method with salt added to it and such encryption doesn't let you to decrypt passwords easily.

Is what i want even possible to achieve? Or is there any other approach i should take instead of hashing but still secure to store multiple passwords to multiple services by a single user?

I will just add to it that let's assume single password or set of passwords is a blog post to view in a plain text only by author of such post and under specific circumstances by admin and moderator.

Technology itself probably is not the most important thing here but i'm going to make this application using php and laravel framework.

To store and to view is one thing, other thing is how to secure such application from various kinds of encrypted posts hijacks, database dumps and similar attacks?

In general:

A one-way hash is non-reversible (hence the term one-way)
Encryption is reversible (provided you have the decryption key)

For regular authentication, we use store password-hashes in the database. Then we hash a user-entered password and compare that to the hash in the database. This way we can authenticate a user without ever storing the password. If the user chose a 'strong' password, it'll be impossible (or at least immensely difficult) to obtained the users clear-text password even if the entire system was compromised.

However, what you're asking for is to retrieve the cleartext password -- which isn't required under most circumstances. The user already knows their password (otherwise they wouldn't have been able to log on) -- and if the user forgot, we'd generally reset the password, by first authenticating an email address or phone number first, and then re-writing the hash for the new password.

If instead you're asking to store 'data' on the account that isn't accessible to anyone without the password -- then the general solution most password-managers utilize is by encrypting the data with key derived from the user password (because user passwords can be quite weak). The data can be a encrypted blob, that would be decrypted on the user-end using their derived key.

The drawback (sort of) is that if the user loses their password, there is no recovering this data, but for most password managers this is actually a 'feature' because nobody wants this data stored in the clear on any server.

Again, the solution would be quite useless if the user chose 'Password1234' as their master password, but there are other solutions for that.


Is the TV show "Person of Interest" realistic? In the real world, can there be a "smart filter machine" that can watch everything we do and theoretically stop any type of terrorist attack? Or has technology not developed enough for something this enormous?

The real question is not if it would be possible to construct a machine which could stop any type of terrorist attack but if you could construct a machine which will stop any attacks without impacting normal live, expected freedom... . If you don't include the second part stopping terrorism is easy already now: kill all people, which of course includes all possible terrorists.

Of course nobody wants this kind of severe side effects. But any technology you use will have some side effects, like tracking the movements of everybody, analyzing everything what you speak and put you in jail in case something you do looks even a bit suspicious.  The question is which side effects are acceptable and which are not. How this question is answered depends on the society, on the (perceived and real) danger of attacks, on the impact of such attacks compared to other problems (like care accidents) etc. In short: it might be possible to have such technology but its side effects of reducing privacy and freedom will be considered too high and most people rather accept some risk.


Best practices for storing and submitting browser fingerprints to secured endpoints I have a large API and JSON Web Tokens (JWT) used for user authorization. These tokens are validated on frontend (nginx proxy) with Lua code. Now I want to secure my API a little more with browser fingerprints. The idea is to store client fingerprint in JWT token and pass this fingerprint from client to server with each request. If fingerprints match together, then it's ok, if not, then we block access, since our token was probably stolen.

There are many ways to create browser fingerprints and Fingerprintjs2 seems like a good solution. What I want to know is how in real world they store this fingerprint (or generate on the fly each time?) and how they submit it to the server (using cookies, headers, get or post parameters).

fingerprinting is used for anything but security, so do not use it for such a purpose.

Since you are using openresty, you can in fact add security to your session handler lua-resty-session has several different options as to where store the session data.

When you read pluggable-storage-adapters you see a table of storage adapters.

For your purpose I would suggest you implement one with Extra Security and implement HMAC.

This will make sure that the session data stays on the server, and that the client only has a HMAC token they can not alter without losing the session.

For additional protection you can add a little code to the authentication Lua to make sure the session is invalidated when the ip source changes.

I hope this answers your Question.

-- Including a comment I made to this awnser.

fingerprinting can be used to enhance the certainty of a specific user, it is however unsuited to replace other means of identification.

(see it like an ID check at a customs officer, your passport Identifies you, its number (and the check done by the automated systems) validates the document is real. and the image of your picture can be used to validate yourself to the officer. So in total while there is only 1 primary carrier of authenticity (the passport) there are many checks done to validate it.

Each check adds to the certainty that the person is who he/she claims to be.
and as part of a authentication scheme you can add the fingerprint as additional information to proof identity. But it should never replace other proofs as its to generic, and to easily to forge or extract through other means.


How can I write a function that will log a user in an old system without knowing any username or password? I'm studying Internet Security and I learned something about code injection in older websites (using the string ' OR 1 == 1 // as a username will log in with any password provided); but what if a password related to a username is stored in the server in a folder with the following path:
/userdata/passwords/<username>

with credentials that will log me into the system, without knowing any legitimate usernames or passwords?
Furthermore, in the question it's specified that the login system is installed on a computer running an OS, and that this operating system is known to have a file with its version (in this case, 1.0.3) in /system/version.txt.
Honestly, I do not know how this last thing can be related to the question, but I hope that someone can help me to understand what could be the right answer and if and how this thing about the system version is related to the answer.
Here is the screenshot of the question of the online test I'm doing:

Judging from the information that you have been provided with, the question relates to LFI (local file inclusion).
Apparently the credentails are stored on the filesystem (/userdata/passwords/).
The question seems to be unrelated to the topic that you have been researching, which is SQL injection. The latter would only be an option if the credentials were stored in a DB, which is obviously not the case.
In order to proceed, I'd recommend you to gather all the information that you can get from your question, and research LFI.
Once you have found the LFI vulnerability, read /system/version.txt (as part of your enumeration, this might give you more insight into further attack vectors) and try to read /userdata/passwords/ (or bruteforce files within that folder) and you'll have a chance to get user credentials.


Is it possible to prove the content of an encrypted message without disclosing the private key? Suppose that I sent Bob a message saying, "The meeting is cancelled", and encrypted it with his public key.

Could he share the plaintext with other people, without disclosing his private key (and therefore compromising the secrecy of the other messages)?

I found this discussion, but I don't think it's a duplicate, or even relevant.

Yes, assuming there is no randomness added to the message during encryption (or that Bob reveals that randomness) then anyone who encrypts the plain-text message with Bob's public key will get the same cipher-text that Bob received / published. That is, of course, assuming that Bob can prove the cipher-text is genuine.


Bell-LaPadula imlementation example I'm currently studying the Bell-LaPadula model and i need to do an implementation as an example.

I understand how the model works, but I have difficulties implementing it in a programming language (for example Java). I consider to have the following classifications:

Restricted,
Confidential,
Secret,
Top Secret

and the following categories:

Lieutenant,
Colonel,
Captain,
Lieutenant General,
General.

How do I represent the lattice?

I suspect you are slightly confused about how Bell-Lapadula works, and in particular, how categories work in Bell-Lapadula.

Classifications are necessarily ordered.  In your example, we have Restricted < Confidential < Secret < Top Secret.  So far, so good.
Categories are, in general, not ordered.  Often, they are a set, with no ordering amongst them.  They are used for compartmentalization, and they are orthogonal to classification.  A compartment is used to further restrict dissemination to a group of individuals with a need-to-know.  Examples of compartments (categories) might be GAMMA (interception of Soviet communications), RUFF (images obtained by satellite), or somesuch.  For instance, the set of categories might be {GAMMA, RUFF}, with no ordering implied between GAMMA vs RUFF.

A document might be stamped, e.g., Top Secret GAMMA RUFF.  For someone to be allowed to read this document, they need both Top Secret clearance, and they need to be authorized to access material in the GAMMA compartment and to access material in the RUFF compartment.  In general, to read some document, your clearance needs to be at least as high as the classification, and you have to be a member of every compartment (category) that the document is labelled with.

Thus, in practice, compartments would never be ranks like Lieutenant.  Your example doesn't make sense.

With this background, each document / data item is labelled as follows:

It has a classification.
It has a set of categories (compartments).

You can represent the classification as @Jeff Ferland suggests.  To represent the set of categories, you'll need to modify @Jeff's suggestion, and store a set of categories.

The most interesting part is not the representation of labels; the most interesting part is to figure out how to compare two labels.  If a document has label L, and a person has label L', should the person be allowed to read the document?  To check that you understand the Bell-Lapadula model, I suggest that you code up this check, for some example.