What terms should I use to define security assessment work? Possible Duplicate:
  What is the difference between a penetration test and a vulnerability assessment?

I am tasked with hiring a consultant to do an analysis of our infrastructure security for a one-time projected based contract.  I would like to know if there is a known term for this type of work that I should be using when looking for this type of service, and if there are any references one might use to build a request for proposal.


Pentesting CTF exercise suggestions for very closed system So I am doing a pentesting/CTF exercise against a very closed system. Only ports 22 (ssh) and 80(unidentified web server) are open. System is Linux.

SSH at least reports an up to date version with no remote vulnerabilities. The web server gives no identifying information what so ever, has nothing enabled, and only returns a 404.

I have performed some vulnerability scans against the host, and not a single finding was found.

The goal of the CTF is to gain root, and gain access to 'Tony Starks' encrypted ironman suit plans, and reverse the encryption.

Along with that goal, a dictionary of top 1000 passwords was provided. I've taken that as a hint that there could be a user with a username somehow based on or related to Tony Stark, trying variations like tonystark, tstark, starkt etc and using hydra with such usernames and the provided dictionary.

So far I have had no luck. I am currently stumped by the complete lack of info and available 'surface area' to attack, and I'm not sure how to proceed further.

Would anyone have some suggestions for further things I could try, or avenues to look investigate?

As with all things penetration testing, enumeration is absolutely critical.

Based on what you've told me, if I were in your situation I would do the following (assuming you have not already).

Ensure you run an nmap scan against all TCP ports

nmap -sV -A host -p 1-65535
Scan UDP ports - this will take a while but perhaps you have an unauthenticated TFTP server you can try to exploit
Run a Nikto scan against the web server - I assume you already did this based on your comment stating that the web server gives no information whatsoever but do it just in case.

nikto -h http://host
Run a dirb scan on the web host to see if you can find some previously unknown directories. You may also choose to use your top 1000 password file as a potential wordlist for this.

dirb http://host -w /usr/share/dirb/wordlists/big.txt
See what HTTP methods are allowed on the web server - is PUT or UPLOAD allowed?

curl -X OPTIONS http://host -i
Try an additional "primary enumeration" tool - instead of nmap, try Sparta which is a wrapper around basic tools which can automatically launch attacks, brute forces etc on detected services
Try running the HTTP-Enum nmap script to see if you can find any additional information that might be useful.

nmap -sV --script=http-enum
Try enumerating SSH users if possible - metasploit has a scanner for this

auxiliary/scanner/ssh/ssh_enumusers

Even though it looks grim now keep pushing forward and keep enumerating your target. The better your enumeration techniques and skills the more likely you are to find a hole to exploit.


Should I return meaningful error code in case of internal error? Let's say I'm using several crypto functions from a 3rd party lib and those crypto functions should never fail because my code, and not a user, is sending all the arguments (buffers, sizes, etc..) so if the function fails it's due to some "internal error".
Let's say I have an rsa function and a hash function, my question is:

If those functions fail, should my code return internal_error error code for both failures? Or should it return rsa_internal_error and hash_internal_error respectively?

Returning just internal_error reveals that an internal error and no more so it's harder to debug if my code can return internal_error from several places in one function.

On the other hand, returning a specific error code for each type of failure makes it easier to debug, but also reveals more information to the user.

Which practice is better?

Does returning specific internal error codes can help attackers in their penetrations attempts?

EDIT: This is an embedded systems so we are cheap on logs. Since this error should not occur (it's not dependent on input or something) we usually don't log those errors.

Which practice is better?

It depends on your needs.  There is no "secure" or "not secure", only "secure enough for my needs".  Which is better depends on your particular risk/benefit tradeoff willingness.  As such, this is rarely an answerable question in a security context.

  Does returning specific internal error codes can help attackers in their penetrations attempts?

Probably not.  You certainly shouldn't be returning stack traces or the like, but a vague error description is probably unlikely to help a would-be attacker.  However, a vague error description is probably also unlikely to be very helpful during debugging.  As a result I'm going to ask the obvious question:

Don't you have logging on in your system?

For instance, in my API calls if there is an error in production I simply return (a JSON document) that says "Internal Error" along with a 500 status code.  This works out well for our front-end developers.  When they see that they just stop and come bug me because they know the problem isn't on their end.  For my part, I then just go look in my server logs which tell me exactly what happened.  There is nothing that can potentially leak to outsiders, and I have all the debugging information I need to fix whatever the problem is.

In short, it sounds like what you need is some detailed logging that is only accessible internally.


How can steganography be useful in a social networking and sharing website like Facebook or Reddit? The point of steganography is to hide useful messages in other messages so that no one suspects the message to contain secrets and tries to crack the message.

The catch is that the recipient should know what that such a message is to be expected and how to decrypt it (find the hidden message).

Steganography helps protect the message while in transit.

In today's social networks and sharing websites like Reddit and Facebook, communication between two people is easily possible with private messages.
These private messages are sent encrypted anyway and steganography isn't really the most reliable way to proceed with.

So how can steganography be really useful?

Is there a use-case where one posts a "steganographed" message on Reddit sub-reddit or a Facebook wall?

Steganography is used to hide messages in plain sight. This is useful to do exactly what you say, "so that no one suspects the message to contain secrets and tries to crack the message."

You suggest that private messages could be used, but that violates the use case for Steg: a private message means that it is known that 2 parties communicated and is potentially interesting.

So, then, using your own words, the use case is simple: you can send a communication that is not known to be a message to someone and have that communication channel itself be unknown to 3rd parties.


Can a 'fingerprint' file be used to track a stolen device? A recent laptop theft, as well as concern that the data upon it might be deliberately accessed (on a drive with encryption or not), head lead me to think about how one might retroactively seek to regain possession of such a laptop, or at least how one might go about gaining leads as to who might have taken it - or where it might be.

If the stolen device were to include a unique file - lets call it Project_X.doc - and this same file were on another device available to the aggrieved, then might it be possible to track down the location of the device through location of the mentioned file?

I am not sure how this might work.

One obvious way would be a trap file that might appeal to a would-be invader that proceeds to send information to a secure email recipient, revealing its location. Kind of virus-like. The only problem with this (besides assumption that it'll be juicy enough bait to bite) is that it involves a degree of foresight and is not a measure that can be applied retrospectively.

The same would apply to registering the device itself with an online site permitting for its tracking. Not retroactive.

Could there simply be two identical files - on for use as a 'fingerprint' file, and another within the stolen device - that could be used to track the location without foresight other than 'happening to have the same file' on another device?

It would also be appreciated if at least a brief 'why yes' or 'why not' could also be included. I am no security pro by many a yard :)

You mean, like say, a MAC address, computer serial number, Windows license key, CPU serial number, hard drive serial numbers, etc, etc, etc.  The problem is, an intelligent thief will either mask, block or change most of these and most of them, while able to be verified when you have a device in your possession are not easy to remotely discover, even if the thief is oblivious to possible technical measures and leaves it on and plugged directly in to the internet 24 hours a day.

This is the basic concept behind how much of the phone home software to prevent laptop theft works, but it still requires that the software go undetected and be connected to a network in order to be able to call home and the first thing any knowledgeable thieves will do is format the computer to be safe, thus wiping out any file or software on it that could help find the thief.

If you didn't have software that calls home installed, there may still be other ways to track it though.  Login cookies, for example, may report themselves to service providers when the thief accesses that website.  If you had your Gmail login saved and they go to Gmail, it will let Google know what IP your laptop is connecting from.  These are pretty hit or miss though since you don't know which services they may access.


Single vs server specific ssh keys? This question has a bit to do with procedure.  Is it better for a person to have one single ssh key pair and share the public key where needed. Alternatively is it better to have server specific keys? or maybe less restrictive have classes or rings of keys.  One key for personal home servers, one for work, one for external stuff like github.

The downside to one key everywhere is clearly that is allows you to be easily tracked and the same public key connects the dots between services.  Revocation is swift but absolute. More finite control is had when you have a key pair per server but it becomes much harder to manage. ssh breaks down when there are many ssh keys and you need to configure your .ssh/config file for each and every site to fix this.  it's a lot of work.

So what are best practices?

Your question is quite broad, and not very specific. It is hard to give advice for such generalities as the recommendations would be different for different people.

As with most security questions start with "What are your protecting? From Whom? What are the consequences of losing this?".

Here are some starting points:

Do you have multiple personas you want kept separate? e.g. Mr Anderson Vs Neo.
If this is the case you will need different key-pairs for each of these personas.
Do you need keys for work and personal?
If so these should be different key-pairs, as your company may consider your key it's property, and may revoke it once you leave the company.
Do you mind your activities being correlated across servers? For me personally the cross persona is more important then the cross service. I don't mind my GitHub/Souceforge/Stackexchange identities being correlated but it would be a shame if it was proven I was The Dread Pirate Roberts.
If so, you need different key-pairs for each of these services.

As you say each key you maintain adds to the amount of effort you need to go to to maintain them. This also raises the possibility of using the wrong key in the wrong place and accidentally connecting your different keys.

The most likely scenario I can see would be someone with 3 personas, [professional , public personal, private personal]. I would be inclined to keep use separate machines for personal and professional, so that my personal private keys never touch my work computers and my works private keys never touch my personal computers. Then depending on the consequences of linking public personal and private personal I would either:

Keep the keys on separate accounts of the same machine (low consequences)
Keep the "public personal" private key on the machine and the "private personal" private key on an encrypted USB device, only plug this in when doing private stuff (medium consequences).
Have a Tails OS or similar for your private work. Again "private personal" on an encrypted USB stick. (medium-high consequences)
Dedicated, physically secure air-gapped machine and some luck (high consequences)


What does it mean by the 'Hash of a malware'? I have just recently started to delve into the topics of malware. In my hunt for malware binaries, I came across certain responses that it is not easy to grab binaries based on malware names like Nugache, Storm, Waledac, Conficker, Rbot etc. from the various databases. These names are, after all, just used to refer a particular variant of a malware, and they are not saved with these references. (This response, in particular, came from honeynet.org)

So I understand that with these names, it would not be possible for me to get the preferred binaries easily.

What I was asked was to provide a list of Md5 hashes of the malware samples that I think would be a RBOT or Waledac etc., and then it would be possible to obtain the binaries.

My question here- what exactly does it means by MD5 hash of a malware sample?
What is it that I am expected to hash?

A hash of a file, means compute the cryptographic checksum of the file.  In a linux/unix operating system, you'd type md5sum name_of_file at the prompt.  Assuming you have GNU coreutils or their equivalent with the md5sum file, like:

# md5sum name_of_file
d41d8cd98f00b204e9800998ecf8427e  name_of_file

where d41d8cd98f00b204e9800998ecf8427e is the MD5 hash of the file name_of_file.

You are expected to have a variety of malware binaries that you can hash yourself, or at least have obtained the hashes of the malware binaries from some other source.


can my internet provider see my communications? Can my ISP see what i am communicating through Skype, Facebook, Yahoo-Mail and so on?

I am not asking this from a legal perspective, but only from a technical one.
Also I am not talking about keyloggers, spywares and similar stuff.

I read similar questions but accepted answers are contradictory to each others so I have no idea which one is right.

The answer is no they cannot, but yes they can.

You have to accept that there is a yes and no to this question, SSL should protect your communication from snooping even from an ISP but if an ISP wanted to do something similar to a MitM they could do so with a fair amount of ease but I will put this down to "similar stuff"....

To reexplain SSL The client and the webserver exchange certificates which are normally signed by a 3rd party to validate that the webserver you are connected to is the genuine one. This SSL checking is to ensure you are connected to the real server and not an attacker, this rule applies to a MitM attack even if done by an ISP you would have to be over an insecure (http, port 80 etc) connection for them to be able to read it. The rules that apply to the rest of the world apply to an ISP they have no special power really, just maybe more resource and a better tactical point in the network infrastructure. so if you are on https your traffic is encrypted and cannot be read.


How do I ensure that my computer is 100% worm-free? Ok say I have a brand new laptop that was is brand new.

Is it true to say that as long as I keep the bluetooth turned off, and I am not connected to the internet, and only copy files that are 100% verified (we can here, assume that it is 100% verified) from a 100% verified hard disk,

And never plug anything into the USB ports,

There can be no way a virus/worm can ever enter my computer?

Basically I'm trying to understand what are all the ways in which a virus/worm can enter a computer?

It depends a bit on what you mean by "100% verified".
With virus scanners, it's always possible that there is a malware program that the virus scanner fails to pick up (false negative). Also, the code might contain vulnerabilities that are not yet public (0-day exploits).
It is mathematically impossible to determine in advance for every program how it will respond to input; this is known as the "halting problem". So automated verification is not enough, for any non-trivial program there will be the need for verification by a human expert - who, of course, may make mistakes, accidentally or deliberately.

You haven't mentioned Bluetooth; there might be buffer overrun vulnerabilities in the code for Bluetooth communication, so you should switch that off as well.

Apart from that, I think you should be safe... but you might as well leave the computer off.

And, of course, this assumes that your computer has no floppy drives through which malware may enter :-)

EDIT: I just realized that malicious code may also be present in data - macros in Office documents being the most likely example. So assuming you're getting data from outside the system somehow, that too is suspect.


OpenSSL brute-force attacking and file size I use OpenSSL with aes-256-cbc to encrypt a 30 GB tar file containing a recent backup of my hard drive. Now suppose somebody wants to run a brute-force attack on this file, trying out all possible password combinations. Does OpenSSL have to scan through the entire 30 GB of data in order to say whether the password matches or whether it doesn't match or can OpenSSL determine really quickly whether the specified password is the correct one?

In other words: Does it take longer to run a brute-force attack using OpenSSL on a 30 GB file than on a 100 KB file?

it depends, but - generally - no. AES is a block cipher, so you're breaknig a thing by 256 bit blocks in your case. And 100KB is more than enough to guess a type of "what's inside", by MIME, for example, after that a task is a way more simplier


Is Ignoring SslPolicyErrors while doing SSL Pinning Secure? I am implementing SSL pinning as a security requirement for a project and the HTTPS endpoint is giving me SslPolicyErrors. The following errors occur,

RemoteCertificateChainErrors
    RevocationStatusUnknown
    UntrustedRoot

This only occurs for our QA endpoint and not our PROD endpoint so I think there could be an issue with the certificate. Both have a certificate chain.

If I ignore these issues and just check that the public key certificate.GetPublicKeyString () matches, will that be secure, or will hackers be able to spoof our certificate because we are not checking the chain?

Here's the code that checks for SslPolicyErrors that I am considering removing.

if (sslPolicyErrors != SslPolicyErrors.None) {
    Debug.Log(sslPolicyErrors);

    for(int i=0; i<chain.ChainStatus.Length;i++){
        Debug.Log("-");
        Debug.Log(chain.ChainStatus[i].Status);
        Debug.Log(chain.ChainStatus[i].StatusInformation);
    }
    return false;
}

Here's the sample .NET code from OWASP.

ServicePointManager.ServerCertificateValidationCallback = PinPublicKey;

-

    public static bool PinPublicKey(object sender, X509Certificate certificate, X509Chain chain, SslPolicyErrors sslPolicyErrors) {
        if (certificate == null || chain == null)
            return false;

        if (sslPolicyErrors != SslPolicyErrors.None)
            return false;

        // Verify against known public key within the certificate
        String pk = certificate.GetPublicKeyString();
        if (pk.Equals(PUB_KEY))
            return true;

        return false;
    }

TL;DR yes it is safe provided that you trust the means by which you came across the value stored in PUB_KEY.

Here is some background that is needed to first understand the purpose of pinning, and why your scenario allows for ignoring of the error. I'll concentrate specifically on PKI in an ideal implementation.

A private key is a very, very large number that meets certain mathematical criteria. With said private key it is possible to derive a specific public key, but the reverse process is so computationally expensive that it can be considered impossible.

"Applying" a public key to data is "undone" by subsequent application of the associated private key, and vice versa. The owner of a private key can thus freely publish their public key in order to receive messages that, for all intents and purposes, only they can read. Conversely they may publish "signed" data that has had their private key "applied"; this allows recipients to be assured that the data was published by the owner of the private key by checking that "undoing" the signature results in the same data.

This process is all well and good as long as parties to communication are knowledgeable of the ownership of public keys. In such a situation communications proceed as follows:

A -> B
B -> A

However an adversary may exploit the lack of knowledge regarding the true ownership of public keys to act as a "man in the middle" (MITM) by falsely claiming to be the expected recipient:

A -> E -> B
B -> E -> A

A and B are none the wiser. This is where the root certificate comes into play. The root certificate is owned by a trusted third party called a certificate authority (CA) who (i) verifies the owners of respective public keys, and then (ii) uses their own private key (linked to the root certificate) to sign a message to the effect of "Person (A|B) owns public key (X|Y)". A and B, already knowing the public key of the CA can verify that the signature is valid. E can now no longer impersonate A or B without compromising the CA.

The CA's public key is known to A and B through means other than the untrusted network on which they communicate. In the event that A and B are already knowledgeable with regards to the other's public key then the need for the CA is obviated; this is key pinning.

You have "pinned" the public key of your server endpoint by hard-coding it into the value of PUB_KEY.

CAs may publish revocation lists to the effect of "I said that A owns public key X but you should now ignore that" (e.g. if the private key is compromised) and the 'RevocationStatusUnknown' error speaks to that effect.

The 'UntrustedRoot' error says that whomever is acting as the CA in this case is not truly trusted. Who is trusted, and how their keys are distributed is beyond the scope of this answer.


WHY the VPN crackdown by China, Russia etc when traffic analysis is possible? So lately its all over the news that China and Russia are soon going to be rolling out a concrete policy that effectively bans the use of VPN's,
not only for their respective citizens but also for foreigners visiting the countries.
The U.K. and Australia are also mulling over similar legislation that seeks to curtail or discourage or inhibit the ubiquitous use of VPN's within their borders.
The U.A.E and Saudi Arabia and other countries in the middle east also have declared VPN use as illegal.
My question is, does the NSA know something that China and Russia have yet to figure out in terms of some breakthrough in fully uncloaking all VPN users based on traffic analysis or traffic correlation?
We have all read the threads which speak about the NSA being able to break "trillions of VPN connections".
Source:
https://arstechnica.com/information-technology/2015/10/how-the-nsa-can-break-trillions-of-encrypted-web-and-vpn-connections/

So is the traffic analysis and real IP unmasking done by Russia and China ineffective compared to the United States NSA?
Or, is the sheer popularity of VPN solutions being adopted by concerned netizens all over the world generating exponentially so much highly encrypted volume of traffic, that the 3-letter agencies in Russia or China are simply unable to keep up with deciphering it all?
Which also makes me curious about the NSA just from a technical standpoint.
We have come a long way since the Snowden revelations in 2013.
A LOT more people are aware of the dangers of using insecure tunneling protocols like PPTP, and more and more VPN desktop clients are pushing the OpenVPN protocols, with users able to choose SHA256 as their payload encryption with RSA 4096bit handshake and also SHA256 authentication (to protect against collision attacks) with the simple click of a button.

Is the NSA STILL able to really break trillions of encrypted connections with the deployment of TLS1.2 everywhere and VPN's all pushing strong AES encrypted OpenVPN connections today as effectively they did in 2013? Or, is the "going dark problem" a real thing?

The aim of these restrictions is probably not traffic analysis but traffic restriction. With a VPN it is impossible to know and to restrict which web sites somebody visits. Without VPN this is possible, even if the transferred content is protected by HTTPS. Also, without VPN it is possible to deny access to specific web sites even if HTTPS is used. With VPN you can only block the full VPN but not parts of the sites visited using the VPN.

China and Russia are both censoring some sites for a variety of reasons. Since VPN work around this censorship it makes sense to forbid the use of a VPN. The USA and most western countries currently don't censor web sites and thus there is no need to restrict usage of VPN currently. But, given the current discussions about the advantages of encryption for privacy and disadvantages when tracking of "bad people" (terrorists, ...) is needed, things might change even in these parts of the world.


How does KEEPASS store images, videos and attached documents/items? I have read quite a bit about KEEPASS and how it encrypts passwords. However, the more I read about it, the more I find how it generates and stores passwords - the methodology provided as well as the documentation all point out to methods that KEEPASS uses to protect your passwords. However, there is nothing said about attachments - such as pictures, videos or documents. Is it all encrypted the same way? I suppose everything is done with AES-256, and the "key transformation constant work factor" that I've read about also just applies about the way password is passed on to keepass and applies to attached items too. Am I correct in these assertions? Any additional information would be much appreciated. Thank you so much !

Keepass 2.0 file attachment security

Already answered via Xander

  File attachments are stored encrypted in the database (like all other database content). http://keepass.info/help/v2/entry.html


Username and password stored under form data in Chrome Dev Tools When I record the network tab in Chrome Developer Tools when logging in to my site I find that the username and password are stored in plaintext under form data.

You can also find it in Safari, Firefox and Opera too.

I tried logging in to various sites like Google, The Verge and Reddit and they all do the same thing as my site.

Is this something to worry about? Is it possible to prevent it?

The developer tools temporarily holds all the data both sent and received for a given page load. This includes everything: passwords, session keys, uploads, downloads. Everything. It also can capture Javascript activity, window draw events, and pretty much anything that is interesting or useful to developers.

If you're worried about it, this is trivial to prevent: don't open the developer tools.

If the tools aren't open during the actual request, then no data will be captured. Opening up the developer tools after the page is loaded gives you an empty trace and the warning, "No requests captured."


Can a Government Intelligence Agency See *Who* I Am Messaging On WhatsApp I have not been able to find this answer, because most of the talk is about the content of communications, but my question is:

Can a government intelligence agency somehow see who I am communicating with over WhatsApp? So generally, I know if I message Bob, they cannot see what I sent, but can they somehow see that I have messaged Bob?

I am asking a 'general' question regarding the published security protocols of WhatsApp, whether it is known or unknown to protect that specific information. I do realize that the intelligence potential of the US government, for instance, is, but in terms of a 'general' type of surveillance, is this probable?

From a technical perspective, it sounds like the metadata is only available by warrant, so if it were a government (other than US or UK) could not produce a legitimate warrant, then would it be safe to say that that information would not be accessible to that government? Most of the conversation around this assumes the PRISM program or a legitimate warrant, but if those are missing, is that data still somehow accessible?

Yes, says Forbes:

  Hence one order (published below) sent to WhatsApp in May 2016, a month after the full rollout of end-to-end encryption was complete. [...] The date, time and duration of comms would be recorded, as would the numbers involved.

However, this article on Softpedia indicates that historical metadata is encrypted:

  As it stands right now, if the FBI would want access to any encrypted WhatsApp data or metadata, Facebook looks poised to put up a fight, just like Apple.

WhatsApp necessarily has the metadata of who communicates with whom, and being a US company they have no choice but to cooperate with warrants that order them to turn over the data.

Note also that metadata is enough to get a conviction. From BBC:

  Sterling was convicted for the most part entirely on phone and email records with no content attached.


Netflix logout does not revoke secure netflix ids I am learning about microservice security and I wanted to see if Netflix really logs me out.
While logged into Netflix, I opened https://www.netflix.com/YourAccount and in inspector viewed headers I am sending.

After copying the headers, I logged out -> opened Postman and issued the same request with the copied headers. The result - I could see my account information so the tokens were not revoked.

Is it a standard to keep auth tokens hanging?

Doesn't it make user of the site more prone to attack?

One benefit of signed auth tokens is the ability to implement them stateless. This means that the server doesn't have to keep track of active tokens, but verifies the validity of a token by checking its signature and the claims contained in the token. Those claims usually contain a short lived expiration date, something like 5 minutes.

A simple logout routine might just delete the token on client side, which results exactly in the behavior you have witnessed. A copy of this token is still valid, until the lifetime has ended.

So you are right - this leaves you vulnerable for a short amount of time, if someone was able to steal your auth token.

The application can actually implement a clean logout, by remembering the active token in a "logged-out list" on server side, until the lifetime of the token has ended. If someone tries to use the token, the server would find its id in the "logged-out list" and denies access. Based on your observation, Netflix decided against this mechanism.


Are sequential patterns used in practice? I study computer security and I read articles about the potential usage of sequential pattern mining in IDPS products:

Database intrusion detection using role and user behavior based risk assessment
Building intrusion pattern miner for Snort network intrusion detection system

I am curious if any of you have seen these sequential patterns and set any rule for them in practice e.g. in a SIEM or IDPS system. I have the impression that most products support only association rules and don't analyse the sequence of the events, packets, etc. I think some attacks can be detected only by checking the sequence, because a single event or packet does not contain enough info about the ongoing attack. I guess most people do this manually instead of using sequential pattern mining and matching algorithms or they use a fully automated system and don't even know about this kind of filtering. Am I right or is this used in practice?

This depends on a lot of factors, like: vendor of the IDS, the settings, which signature is being triggered and what kind of attack is being initiated. In short yes, UTMs of the common vendors (CP, Fortinet, PANW) all store a copy of the traffic in memory for analysis.
For instance, you could configure in an IDS that a RDP Brute-force attack is only flagged as such when the signature has been identified X amount of times in the last N seconds. This is to prevent any false positives, especially when you have an IPS blade on top of it conducting preventive actions.
With regards to SIEM this completely flexible, you can build use-cases in numerous ways and correlate alerts from  various sources. For instance in the case mentioned above, you could correlate this with the log sources from the source-device and a Directory Service.


Will using CTR mode with unique IVs, but only one password for encrypting multiple files, leak data or keys? I'm working on a project to encrypt many files with a single password.

The steps I will employ to encrypt the files are:

user will execute a command similar to tool --encrypt --recurse directories/to/recurse and-other-files.txt
the user will be prompted for a password
two 64 byte crypto random salts and a 16 byte crypto random IV will be generated
no 2 files will ever use the same salts or IV
each individual salt will be combined with the password to create to 2 separate argon2id keys
one key will be 32 bytes long and is used for the AES-256 cipher block
the other will be 64 bytes long and will be used as the key for a sha-512 hmac
the resulting encrypted file will be written as 2ByteVersion:64ByteHMACSalt:64ByteCipherBlockSalt:16ByteIV:EncryptedData:64ByteHMACSignature

I believe this would result in a reasonably secure, set of encrypted files. My main concern though, is that because of the way that users will use this tool, there is a good chance that they will accidentally encrypt small, easily guessed files.

And since CTR mode doesn't require padding, anyone with access to the encrypted file will know the length of the plaintext file. It seems that CTR mode is considered secure for files, provided the IV is unique for each encryption run and the file is authenticated.

Is there a chance that the cipher key, HMAC key, or password could be derived through a known plaintext attack from enough small guessable files? Are there any other glaring flaws in my methodology that could leak data?

No, using different salt (IV) under the same key doesn't leak information. The problem with the CTR mode is the IV-reuse under the same key. Since CTR mode turns a block cipher into a stream cipher, re-using the IV with the same key will produce the same output stream that is similar to the reuse of One-Time-Pad (OTP). As in the OTP key is reuse, the information can be extracted with crib-dragging techniques.

There are better alternatives to what you are trying. There are Authenticated Encryption (AE) modes like AES-GCM and ChaCha20-Poly1305. AE mode ciphers can provide you Confidentiality, Integrity, and Authentication all-in-one. TLS version 1.3 has these algorithms in the standard.

With AE you don't need to provide two keys. If you are insisting to use HMAC, you can use a good Key Derivation Functions like Argon2id. By providing different salts you can derive two different keys.

Encryption, in general, doesn't protect the plaintext size ( if padding is applied the output size is always multiple of the block length in block-ciphers, which is not a case for CTR mode). The input size equal to the same output size plus IV and tag those sizes are known to the attacker. One way to mitigate, you can add some random characters at the end of the files. That must be uniquely removable like paddings. This can be helpful if you cluster the file into groups i.e make the size fixes length at some intervals.

Breaking the CTR mode with Known-Plaintext Attack (KPA) is equal to Breaking AES. Apart from the side-channel attacks, cache attack, power attacks, we believe that AES is KPA-secure. Since the attacker cannot access the key, they cannot find the password in this way.

The password, on the other hand, must be strong against the brute-force attacks. This may be the weakest point of your system.

If you consider only securing your files, there are already good alternatives for you; VeraCrypt. With VeraCrypt, you can create an encrypted volume and you can store your files in it. From your password to encryption/decryption of the volume are all handled for you.
It is cross-platform, and you can access your files from Windows/Linux/Mac. You can find some third-party for your mobile devices, too.


Any security vulnerability using filenames generated from database? Ok, for example, say you have settings stored in a database where the user selects the language of the site.

For example, say the language they chose was English and now has a setting of en.

Then within your scripting language such as PHP you generate the path to the file and include it as usual, such as:

<script type="text/javascript" src="<?=$home_url?>/languages/<?=$lang?>.js"></script>

I know this value should be safe and really if some malicious user has somehow gained access to the database then we likely have bigger problems to worry about, but I guess it's possible a security flaw somewhere made it possible to be able to corrupt the value of this field and insert some unexpected and malicious data.

Though I assume they couldn't do anything too nasty seeing as the inclusion of <?=$home_url?> should prevent anyone from including any files from a remote server?

Even though I only half agree with you on an attacker having access to the DB not being worth protecting against, I would still say that this is not a big issue for a couple of reasons:

Since the include is client side and not server side, you do not risk exposing any sensitive files that are not already exposed. Had it instead been a PHP include() you would have bigger risks, since it can reach files that can not be reached over HTTP.
Probably only files on your domain can be included (but using /../ could let an attacker traverse to other directories). But if you have an open redirect vulnerability on your side it could be used to include files from other domains. That would be dangerous.
As I understand it, the user can only set their own language. So even if this was exploitable it would be hard to "deliver" the exploit to other users.

But still, there is no reason to take unnecesary risks even if they are small. This can be easily defended against:

Validate the data in the application layer, so the user can not set a language that is not on your list of languages. So if they try setting ../evil_javascript.js it will fail.
Make sure only country codes can be stored in that database column, e.g. by using a foreign key to a languages table or perhaps a check constraint. This way, you know a user can not sneak in any strange values even if the validation in the application layer should somehow fail.
Then validate the data as it comes out of your DB. You could make a check like this (but perhaps with nicer error handling):

if(!in_array($lang, $language_list)) die("Unknown language!");

Or just doing this would take the teeth out of any attack:

<script src="<?=$home_url?>/languages/<?=substr($lang, 0, 2)?>.js">

This might seem a bit execive for a low risk thing. But at least the first and second point is good practice anyway, even if you don't take security into consideration.


Allow access only for some Mac Ids There is an application which shows a login page. However, I do not want people to login through any machine. I want to restrict login to a few Mac Ids. Is there a way to do this?

There is probably a way to get the MacId from a java applet or ActiveX control, but how would a call which spoofs the MacId in a modified Applet be prevented?

You cannot prevent the spoofing of a MAC. Your attempt will help restrict ordinary users, but will not prevent an attacker from accessing it.


Angular (2+) code visibility to users I'm looking into Angular and read that typescript is compiled to javascript. Is everything viewable/visible to users that I write using typescript?
With PHP I know you run code that's only visible to the server. Does Angular also have code visible only to the server or is everything visible to everyone?

There is a reason I'm asking this and let me create a simple scenario where I find this information relevant:

You have server A which publishes REST services. Server A only allows server B to access it (ip whitelist and such). Server B calls REST services from server A. These REST calls are unsecured and do not require authentication because only server B can call those rest services.

Can a user see the rest calls the Angular website makes?
If yes, can a user abuse these unsecured REST calls somehow?

Unlike PHP, Angular is a frontend framework. All frontend code is visible to the end user.

All network calls are also visible to the end user, even if it's encrypted with HTTPS. Encryption will only protect against man-in-the-middle attacks. An IP whitelist will not.

Although only a whitelisted IP can successfully receive data back from the REST service, any unencrypted data is susceptible to being read and modified by anyone snooping on the network between the client and the server.


Why are Synchronization Token and Cookie-to-Header patterns un-natural for Web APIs? I have heard that CSRF prevention techniques are not natural for Web APIs.

For instance, we might have a client application at domainA that implements both the Synchronization Token Pattern and the Cookie-to-Header pattern. When the client POSTs to the resource server at domainB, the resource server needs to validate those security values, and since the resource server would not know what synchronization token value nor what cookie-to-header value to expect, it will have a hard time validating those.

That being said, the resource server could validate the synchronization token and/or the cookie-to-header value using the same technique that it uses to validate the access token. Given that, why are those two techniques considered inappropriate for a Web API?

In a Web CSRF flow, the server sends the token as part of the response that serves the webpage, so the token is delivered "for free". Typically, the same server is also the target for those POST requests so it can easily validate the tokens.

When you call a Web API, the target is probably a different server so the token will either have to be communicated out-of-band or the client will have to send a request just for the token to use in a subsequent request. In either cases, the Web API server handles double the number of requests, which is wasteful.

Good alternatives are digital signature schemes or HTTP methods/headers not allowed by browsers.


Why is Math.random() not designed to be cryptographically secure? The JavaScript Math.random() function is designed to return a single IEEE floating point value n such that 0 ≤ n < 1. It is (or at least should be) widely known that the output is not cryptographically secure. Most modern implementations use the XorShift128+ algorithm which can be easily broken. As it is not at all uncommon for people to mistakenly use it when they need better randomness, why do browsers not replace it with a CSPRNG? I know that Opera does that*, at least. The only reasoning I could think of would be that XorShift128+ is faster than a CSPRNG, but on modern (and even not so modern) computers, it would be trivial to output hundreds of megabytes per second using ChaCha8 or AES-CTR. These are often fast enough that a well-optimized implementation may be bottlenecked only by the system's memory speed. Even an unoptimized implementation of ChaCha20 is extremely fast on all architectures, and ChaCha8 is more than twice as fast.
I understand that it could not be re-defined as a CSPRNG as the standard explicitly gives no guarantee of suitability for cryptographic use, but there seems to be no downside to browser vendors doing it voluntarily. It would reduce the impact of bugs in a large number of web applications without violating the standard (it only requires the output be round-to-nearest-even IEEE 754 numbers), decreasing performance, or breaking compatibility with web applications.

EDIT: A few people have pointed out that this could potentially cause people to abuse this function even if the standard says you cannot rely on it for cryptographic security. In my mind, there are two opposing factors that determine whether or not using a CSPRNG would be a net security benefit:

False sense of security - The number of people who otherwise would use a function designed for this purpose, such as window.crypto, decide instead to use Math.random() because it happens to be cryptographically secure on their intended target platform.

Opportunistic security - The number of people who don't know any better and use Math.random() anyway for sensitive applications who would be protected from their own mistake. Obviously, it would be better to educate them instead, but this is not always possible.

It seems safe to assume that the number of people who would be protected from their own mistakes would greatly exceed the number of people who are lulled into a false sense of security.
* As CodesInChaos points out, this is no longer true now that Opera is based off of Chromium.

Several major browsers have had bug reports suggesting to replace this function with a cryptographically-secure alternative, but none of the suggested secure changes landed:

Chromium thread: https://bugs.chromium.org/p/chromium/issues/detail?id=45580

Firefox thread: https://bugzilla.mozilla.org/show_bug.cgi?id=322529

The arguments for the change essentially match mine. The arguments against it vary from reduced performance on microbenchmarks (with little impact in the real world) to misunderstandings and myths, such as the incorrect idea that a CSPRNG gets weaker over time as more randomness is generated. In the end, Chromium created an entirely new crypto object, and Firefox replaced their RNG with the XorShift128+ algorithm. The Math.random() function remains fully predictable.

I was one of the implementers of JScript and on the ECMA committee in the mid to late 1990s, so I can provide some historical perspective here.

  The JavaScript Math.random() function is designed to return a floating point value between 0 and 1. It is widely known (or at least should be) that the output is not cryptographically secure

First off: the design of many RNG APIs is horrible. The fact that the .NET Random class can trivially be misused in multiple ways to produce long sequences of the same number is awful. An API where the natural way to use it is also the wrong way is a "pit of failure" API; we want our APIs to be pits of success, where the natural way and the right way are the same.

I think it is fair to say that if we knew then what we know now, the JS random API would be different. Even simple things like changing the name to "pseudorandom" would help, because as you note, in some cases the implementation details matter. At an architectural level, there are good reasons why you want random() to be a factory that returns an object representing a random or pseudo-random sequence, rather than simply returning numbers. And so on.  Lessons learned.

Second, let's remember what the fundamental design purpose of JS was in the 1990s.  Make the monkey dance when you move the mouse.  We thought of inline expression scripts as normal, we thought of two-to-ten line script blocks as common, and the notion that someone might write a hundred lines of script on a page was really very unusual. I remember the first time I saw a ten thousand line JS program and my first question to the people who were asking me for help because it was so slow compared to their C++ version was some version of "are you insane?! 10KLOC JS?!"

The notion that anyone would need crypto randomness in JS was similarly insane. You need your monkey movements to be crypto strength unpredictable? Unlikely.

Also, remember that it was the mid 1990s. If you were not there for it, I can tell you it was a very different world than today as far as crypto was concerned... See export of cryptography.

I would not have even considered putting crypto strength randomness into anything that shipped with the browser without getting a huge amount of legal advice from the MSLegal team. I didn't want to touch crypto with a ten foot pole in a world where shipping code was considered exporting munitions to enemies of the state.  This sounds crazy from today's perspective, but that was the world that was.

  why do browsers not replace it with a CSPRNG?

Browser authors do not have to provide a reason to NOT do a change.  Changes cost money, and they take away effort from better changes; every change has a huge opportunity cost.

Rather, you have to provide an argument not just why making the change is a good idea, but why it is the best possible use of their time.  This is a small-bang-for-the-buck change.

  I understand that it could not be re-defined as a CSPRNG as the standard explicitly gives no guarantee for suitability for cryptographic use, but there seems to be no downside to doing it anyway

The downside is that developers are still in a situation where they cannot reliably know whether their randomness is crypto strength or not, and can even more easily fall into the trap of relying on a property that is not guaranteed by the standard.  The proposed change doesn't actually fix the problem, which is a design problem.


Is a large number of RSA-encrypted files a vulnerability? Would having a large number (10^4) of RSA encrypted files make it easier for an attacker to find my private RSA key?

Update: These files would be available to the attacker, and perhaps the content of a few of them could be guessed. The GnuPG implementation with a 2048-bit RSA key would be used, and the public key would be public.

Short answer: there is no issue in encrypting 104 files with the same key.

Longer answer: it is called public encryption for a reason: the public key is, well, public. This means that anybody can encrypt data with the public key (it is the decrypting part which is reserved for the private key owner). In particular, the attacker can encrypt millions of files with your public key, if he wishes so. Asymmetric encryption systems are specifically designed to not suffer from that. In the case of RSA, this implies that any decent RSA encryption protocol includes random padding bytes, as PKCS#1 describes; the protocol used by GnuPG to encrypt data is decent.


Mount ecryptfs directory via SSH I have access to a server that I use for backups. I use rsync with the --delete flag to make an exact copy of my backup directory. I have no need for incremental backups. The backup directory on the server is encrypted with ecryptfs (although not the whole home folder). I have written a script which is stored locally and executes over ssh on the server which:

Decrypts and mounts the directory
Performs rsync
Unmounts the directory
Sends me an email

The password to decrypt the directory is stored on the local machine. I am using:

key=passphrase:passphrase_passwd_file=/home/me/password.txt

in the mount command. My question is; does this pose any sort of security risk? I can't see that it does but I noted on the ecryptfs man page that using passphrase_passwd option (which I realise is different to the one above) should only be used when security is not important as the password is visible to utilities like ps. Permissions on my folder are set to 700.

Your password can be viewed by processes in the server, since you are executing the ecryptfs there.

What you can do is to mount the ecryptfs locally. I see two options:

Mount the server folder locally with sshfs and then ecryptfs over it.
Reverse-mount the source folder and rsync those encrypted files to the server.


Industry Certification Question I have been researching cybersecurity industry certifications for some time now and I am looking for some guidance/input on what combination of education, experience, and certification is best suited for working in the cybersecurity industry.

To give a bit of background I have a Master of Science in Cybersecurity from a reputable, accredited university and three years of experience in information technology related fields, but not directly in cybersecurity. This makes it hard to obtain positions in the field and mid-level industry certifications with work requirements due to the lack of directly related experience.

How does one break into the cybersecurity industry given this scenario?

This makes it hard to obtain positions in the field and mid-level industry certifications with work requirements due to the lack of directly related experience.

Security is a hot field so there are no shortage of players in the market looking to capitalize on this by getting into the certification space. Be careful what you sign up for.

SANS stuff is expensive but always respected. (This doesn't mean it's good, just that it's a useful credential)
OCSP is supposedly brutal and separates the men from the boys, but nobody in a position to hire you will have ever heard of it.
CEH/Security+ is a joke (see above warning; both are beneath you and exist only to siphon DoD 8570 money).

The insult to people like yourself is that you went to the trouble of getting a Master's, yet the implication is that you're not qualified unless you also go out and buy an overpriced certificate and pay to maintain it.

  How does one break into the cybersecurity industry given this scenario?

Start by being more specific and focus on that. There is no job title of "cybersecurity." But there is application security, network security, malware analysis, digital forensics, penetration testing, security engineering, security analysis, etc.

Then, relocate. Are you in middle America? Get out. Go where the financial and defense industries are, typically on either coast. Many of the security vendors who sell to them are located in California (San Jose, Sacramento, mostly northern). Go where the market is.

With a degree in something as broad as "cybersecurity," you've aligned yourself with the management track. Pursue that. You'll probably need a SANS cert. If you don't want to be management, pick a particular niche of security and beef up your technical skills in that domain (ex. for network, go the CCNP/CCIE route).

Not that it's impossible, but most people who end up in mid-level security-related positions did not start there. They tend to cut their teeth in a more technical domain first and build from it-- networking experts who've seen enough threats in the field to know something about it, developers who know how to break applications because they've spent enough time building them, etc. Myself, I cut my teeth as a sysadmin dealing with threats to infrastructure as a matter of course-- trial by fire.

I don't have any certifications. It hasn't stopped me from progressing in my career on either coast. The only qualification I don't have that has actually impacted me is lack of a security clearance-- it makes it very hard to get anywhere in the defense industry.


Isn't HTTPS enough to prevent MITM in mobile apps? Why is SSL Pinning needed? I am making a webview that is going to be part of a native iOS and Android app, I implemented the webview using HTTPS as a protocol, and developed my NodeJS app there.
But the security team from where I work, came with the following situation:
"what if the phone that has the app is connected to a malicious router, and redirects the URL of the webview to another IP with has a server with malicious content"
And he told me to use SSL Pinning to fix the problem, but I'm not sure that this scenario can happen because I'm using HTTPS, I believe that HTTPS only already gives the protection I need against MITM.
If the router redirects the URL to a malicious server, the server will never have access to our SSL/TLS certificate, it can self-sign one, but it will never have the CA root certificate signed, so the webview will show "This website is insecure" kind of warning.
He went on, and said that if the user has a compromised device, he can generate his own CA, and put into the client's device, so it will handshake an HTTPS connection, while I see that this can happen, this isn't MITM, and I don't know how SSL Pinning can help in this case either.
The only case  I see SSL pinning being useful, is if I want to prevent my URL from opening anywhere other than the app webview, but it is the only situation I can imagine.
Am I thinking the right way here? would love to see you guys opinion in this.

If you use https as protection you basically trust the whole set of authorised CA’s. Any one of them can (through trickery or by intent) issue a valid certificate for your domain.
There is also the case that there are quite a few corporations / schools that require you to install their CA root certificate (with a lot less protection than the commercial CA’s)
You also have the people that use tools like burp suite to intercept the traffic between the app and your server.
Certificate pinning protects against all these issues. It will prevent a different server from talking with your app. Whether targeted and on purpose or malicious and criminal, it’s usually a good idea to add the layer of protection that pinning the certificate will add even with the additional effort of maintaining it.
In short, certificate pinning is another layer for defence in depth, making it harder for both malicious as criminals from abusing the app and your server for any purpose other than the intended.


Spoofed email: can't determine Purported Responsible Address I am studying the SMTP protocol and follow a course materials to setup a PoC spoofed email by talking with a SMTP server of our department.

This is what I have right now:

shuaiw@shuaicpu1:~$ telnet mail.XXXXXX 25
Trying XXX...
Connected to mail.XXX.hk.
Escape character is '^]'.
220 XXX ESMTP ; Mon, 4 Nov 2019 16:07:07 +0800
HELO random.org
250 XXX Hello 191host060.mobilenet.XXX [XXX], pleased to meet you
MAIL FROM: <test@random.org>
250 2.1.0 <test@random.org>... Sender ok
RCPT TO: <XXX@XXX>                      <---- this is a valid email address
250 2.1.5 <XXX@XXX>... Recipient ok
DATA
354 Enter mail, end with "." on a line by itself
this is the email body
.
550 5.7.1 can't determine Purported Responsible Address

I was expecting to send this message out but however, it returns can't determine Purported Responsible Address. Could anyone shed some lights on this? Thanks a lot.

DATA
354 Enter mail, end with "." on a line by itself
this is the email body
.

You don't send any mail header which also means that you don't send any From field in the mail header which means that server cannot extract From and use it for verification. See also RFC 4407 - Purported Responsible Address in E-Mail Messages.


How secure is our privacy when using third party addons and extensions? I use many addons and extensions in my browsers some of it is for ad blocking, taking screen shots and VPNs. This question came to my mind while using free VPN addons. I usually uses VPN addons for watching videos which are IP blocked but switch offs ( in the image down right side on/off toggle button ) while using banking transactions, emailing and other personal and secure tasks.

I know that while switching on VPN; those companies monitor our browsing history and possibly save it in some databases. If we switch off our VPN will it still log our browsing history and send it to their databases. Can other installed add ons see/send user browsing history without their consent?  Is their a add on/ extension which can monitor the behaviour of other add ons similar to firewalls in desktops?

As soon as you install an add-on in your browser, you assume it to be fair. If you do not, you should not install it at first.

Using a free add-on without carefully analizing what it does, how it does it, and why the developper gives it for free is not really different that asking an unkown guy in the street to protect your house from (other) thieves and give him the keys. It may or not be efficient...

Now for the technical part. An add-on can be activated/de-activated at 2 possible levels: in the configuration options of the browser, or in its own configuration page (what is shown in question). When it is de-activated at the browser level, all is (well should be...(*)) fine: the browser does not call the add-on, so it cannot do anything; But when it is de-activated in its own configuration, it is still called by the browser so it can still monitor all the activity.

If an add-on is really malicious you cannot be totally sure of what exists in the system once it has be used once, even if you deactivate or even remove it. It has got the possibility to execute arbitrary code at user level. It should not have be able to process tasks requiring administrative priviledges (assuming you to not browse internet with an admin account), but could have changed user profile to run tasks at login. No decent plugin should do that, but if you have installed many plugins one could not be decent...

One security rules says:

  If an evil guy could persuade you to run his code on your machine, it is no longer (only) your machine.


Stop User Enumeration requests on AJAX endpoints I have an ecommerce website with over 5 million customer database. From past couple of days, probably a hacker is hitting an AJAX endpoint continuously. This endpoint takes email address as a parameter and returns whether that email address is registered on our website or not, and we accordingly prompt user to login or signup. My bet is that this hacker is trying to exploit User Enumeration vulnerability.
I have employed various measures to stop this hacker, but he seems to be very smart. I am getting hits from all over the world and hundreds of differents IPs in each country. Which is making it extremely difficult to block him.
To stop him, I have done following:

Applied rate limit using AWS WAF - not more than 100 requests per 5 minute from single IP on this endpoint.
Blocked over 1500 IP address manually going through Access logs
Blocked complete traffic from over 50 countries which doesn't contribute much in revenue.

Although above steps has curtailed the speed of attack a lot. But that guy is still running this attack and it's not possible to keep on blocking IP addresses or countries because he keeps on bringing new IP address.
What can be a good way by which I can stop him without hampering our genuine user's experience? I don't want to introduce captcha, is there any other way?

The cause of your problem:
Your system has a major design flaw where it's giving away information that it shouldn't offer openly. You've created a leak and someone is using it against you.
Now you could go great lengths to get get rid of the hacker, but in the end you're simply fighting windmills trying to block someone who's using a botnet. And even if you actually succeeded in the end - which is extremely unlikely in the first place - all you're doing is treating the symptom instead of the actual problem.
How to solve this:
Legitimate users know whether they're signed up already or need an account first. So fix your login form, nuke that endpoint and you're good.


If an application has an XSS vulnerabilty, can we bypass CSRF with referer header? Let's say there is an XSS vulnerability in an application, and the application is not using any kind of CSRF token, just using the referer header to protect against CSRF. Referer header is validating properly. So in this case can we bypass the referer header to perform the CSRF? If yes, then how?

Because OWASP always recommends token to prevent CSRF...

If there is an XSS vulnerability, the attacker has won. If you can execute arbitrary JavaScript on the victims machine in the target origin, you can do whatever you want - you don't need to bypass any CSRF protection to wreak havoc.

Also, no CSRF protections survive an XSS vulnerability. A referer header check does not help, since the attacker can just send the requests with the injected script, so they will have the right referer. A CSRF token doesn't help either, since it can easily be exfiltrated.

In short, XSS > CSRF.


Is Window's system restoration useful for getting rid of malware? If your computer has been infected with some kind of malware, could a restoration of the system, using the tool provided by windows, help you getting rid of that malware?

We should suppose that it exists a restoration point before the infection, and also that the date of the infection is known.

System restore does not track all system changes. This is a myth. Most files are not covered by system restore, and certain system settings (e.g. BCD) are not affected by a restore.

System restore makes backups of:

Registry hives
Resources monitored via Windows File Protection
The local user profile
COM+ and WMI databases
IIS metabase

It also keeps tracks of changes to files with certain extensions, in order to provide diff-based backups.

Since most malware persists on disk, with a registry key to make itself start on boot, a system restore should disable most malware. It most likely will not remove the malware from the disk, though. Other persistence mechanisms, such as code injection, will allow the malware to persist beyond a system restore.


What are the risks of a self-signed client certificate? I understand the risks of a self-signed certificate used to enable HTTPS on a server.

My question, however, is about HTTPS client certificates.

Imagine the following scenario. I want to be able to authenticate a bunch of tech-savvy users on a public website without requiring them to pass through OpenID or requiring a password.

I start by generating a self-signed root certificate that I store on the server. In the context of this question, let's assume this root certificate will be protected against hackers.

From this root certificate, I generate several client certificates, one for each user, and transmit the .p12 file to those users in a safe way. They add those certificates to their browsers, and can now be authenticated.

Is there any security issue that the root certificate was self-signed? How would this compare to, for instance, using Let's Encrypt derived certificate as a root certificate (which is possible to do, since I do have the private key on the server as well)?

It seems to me that in terms of certificate revocation, it is as simple as regenerating the certificate, would it be the root certificate if this was the problem, or a client certificate. Is there anything else I'm missing?

What you are doing there is basically becoming your own certificate authority - which is fine, as long as you accept the risks associated and/or mitigate them.

In this scenario you can safely base your servers trust in your own certificate to issue client certificates as long as you are fine with your own CAs method of establishing trust in the users identity.

I’m not too sure let’s encrypt will give you a certificate that has the CA attribute set (i.e. can act as a certificate authority). While you might have the key for the certificate, that certificate does not allow signing certificates itself.

Certificate revocation should be handled internally (your server should know which certificates should no longer be accepted) at least; you do not need to provide CRLs if you only use the CA internally.

You can also establish a 1:1 connection between user and certificate, replacing the revoked certificate with a new one should be fine then.


Is it advisable to fully record terminal interaction for incident response? We are going to be using a jump box to serve as an SSH bridge to our production systems.  Assuming that operators are actually logging in to a shell on the jump box and assuming that it is possible to record the full terminal interactions, is it advisable to record full terminal interactions in this kind of scenario?

I am thinking that having those interactions recorded would serve as a great tool for postmortem reports and possibly for training purposes too.  However, in what documentation I've read about computer incident response, I have never seen any mention of recording the terminal during the incident.

Yes, it's definitely advisable. In analysing an incident, you'll always want to have as much information as possible. Having too much information is better than not having enough as you don't want to be guessing links between actions.

For reviewing an incident, you'll want to know who did what when. In order to do this, you'll want to know the authentication so you know the who, you'll want the commands entered so you know the what and you'll need NTP sync'd so you know the when.

Depending on the system, some activity may not be captured in full when a user with privileges drops to a shell prompt. In these instances you may want to implement additional controls to prevent this or add software to detect it.


Are there faux/fake malicious websites to test web reputation services similar to EICAR? Antivirus writers have agreed for their software to recognize a standard "fake" virus file - the EICAR file, to let users check, that the software is up and running.

Are there any equivalent test sites for trying out McAfee SiteAdvisor, Kaspersky URL Advisor, Norton Safe Web, Google Safe Browsing, and others?

Or can anyone share any running sites, which they use to test out whether their reputation services are working?

Unfortunately Google Safe Browsing doesn't recognize "malware.wicar.org" of http://wicar.org/ as a malicious site.  Instead you can use http://www.ianfette.org/ which is, I guess, the Google Safe Browsing test site.

Just in case you are wondering, Ian Fette is a software engineer at Google.


Spam email sent to my contacts pretending to be me. I just found out someone has been sending spam emails to my contacts.
I first thought that my account was hacked, but the emails aren't coming from my account but from a weird email address (my name followed by @deanglyn.freeserve.co.uk). That's really annoying as most of my contacts are work related.

Does this mean that my email account has been hacked or that someone just got access to my contact list? I'm wondering because if my account was hacked, why use a weird email address?

What do you think I should do?

Thanks.

You are looking at it in the wrong way. One of the following scenarios is probably happened:

The attacker gained your contact list and used their email to spam your contact list - In this case I suggest you look over apps/programs that are installed on the device you use for checking your email.
Attacker has hacked your email account and stole your contacts and then spammed them using their own email so your email provider wont block them (They might connect through an API or try sending all kinds of spam that your email provider might have blocked) - In this case I suggest you change your password and keep alert for any suspicious activity (You might want to check how they managed to hack you)

I also suggest you use haveibeenpwned this website to see if you were hacked.


Ideas to build security awareness It has been claimed that "the weakest factor in security is the humans". Unfortunately this is a weak link we cannot cut away so we have to deal with it.

I need ideas to help build inherently security awareness in an organization. I had a few ideas myself:

All clients have a mandatory screensaver which displays statements like "Remember to lock your PC", "Always wear a visible badge", "Do not let anyone follow you into a locked door without asking them for a valid key card".
Send SANS Ouch! newsletter to everyone.
Quiz people in security awareness annually
Present the OWASP Top 10 to relevant personnel, e.g. developers.

What are your ideas for building security awareness?

Love the suggestions you gave so far, I'll be keeping them in mind for future reference!

My #1 suggestion would be to attack your own employees. I don't mean you should run around with an axe all "Here's Johnny!" style, screaming at people about proper security practice, but rather stage cyber-attacks and judge their responses, then explain to them what they did right / wrong. People learn through experience much better than they learn through reading an email.

One of the easiest and most effective methods to try is an external website containing a login screen, with the company logo. Send out emails to employees from an external account, claiming to be the sysadmin, saying you've got a new staff portal. Every time a user logs in, have it direct to a page explaining what they just fell for and how they can recognise it in future. Include your phone number and email address in case the user wants to know more. Every time a user calls you up to ask if it's safe, or to report it as a security issue, tell them they did the right thing and make sure their line manager is aware of their success.

Next one to try is a more direct one. Send out an email (again, from an external mailbox) saying that the database is having problems and you've got to re-enter everyone's passwords. Ask them to send their passwords to a "secure password update mailbox", and wait. Every time someone sends a password, explain to them that they just fell for a phishing attack. Downside of this attack is that you'll have to reset a lot of people's passwords!

Just one word of advice: get authorisation to do this before you start the project! ;)


Does read-only access to the database prevent sql injection? I have a web api that connects to my SQL Server using a read-only connection and want to allow tech savvy users of my api to enter an SQL where clause on the querystring. I basically just want to tack what they enter onto the select statement.

Does a least-privilege (select ability on one table only), read-only connection to the database prevent all injection attacks?

No.  You might be confusing SQL injection with data injection; read-only tables do not prevent SQL injection and at best do only a little to limit its impact.

SQL injection simply means the ability to inject SQL code.  While read-only tables may limit the ability to inject data into the table, they don't impact the ability to:

Read from other databases or tables if not disallowed
Read from system tables or run other system queries which are hard to disallow
Write excessively complex queries that will perform a DoS
Exfiltrate data using DNS
Access local files (e.g., utl_file in Oracle)
Access the DB server's network (e.g., utl_http in Oracle)
Execute arbitrary code on the server via DB function buffer overflows
See Advanced SQL Injection in Oracle databases for a good walk through all the sorts of things you need to worry about (and realize other databases have their equivalents)

If you

  basically just want to tack what they enter onto the select statement.

then you're expressly permitting the attacker to try any of these.

Now, you can certainly do things to limit this.  You can disallow quotes and SQL statement separator characters.  You can disallow any input that's not [A-Za-z0-9"=] (or effectively equivalent for your database).  But if you start going down this path, you're better off writing your application correctly: Expose a richer query interface where you offer the keys to be checked and then you perform proper quoting on whatever values the user enters.


Protection against Keyloggers? I was wondering, If I got infected with a Keylogger and I start my On-Screen Keyboard(from OS) and type things, will the symbols will be recorded (considering no Screenshots Keyloggers)? Since Keyloggers act on keystrokes I think this may work against Keylogger, correct me If I'm wrong.

If you are infected with a keylogger, it is a software keylogger and a software keylogger does not monitor the keyboard, it monitors the events that the OS fires off when a key is pressed.  These events are fired regardless of what type of input you use.  If a letter is generated as input, then it had to go to the OS and request the key be processed and the software keylogger will have seen it.

A hardware key logger is a physical device that is installed in-between the keyboard and computer and doesn't have to infect the computer since it is capturing the signals from the keyboard itself, but these are very rare since they have to be applied physically to the computer.


openssl serial number error "SEC_ERROR_REUSED_ISSUER_AND_SERIAL" I've been experimenting a bit with self-issued certificates.

I set up a certificate authority, issued a certificate, and installed it on a webserver.
I later deleted that certificate without bothering to revoke it, and decremented the number in the serial.txt file which openssl was using. (There was no good reason to do so, but it seemed a harmless thing to do).

After that, I used the certificate authority to re-issue a new certificate.
When I install that certificate on the webserver and access it, Firefox shows me an error:

  Your certificate contains the same serial number as another certificate issued by the certificate authority. Please get a new certificate containing a unique serial number. Error code: SEC_ERROR_REUSED_ISSUER_AND_SERIAL

I assume I am getting this error because of the fact that I decremented the serial.txt file, so the newly issued certificate had the same serial number as an older incarnation.

My questions are:

How does my browser know this? Does it keep a database somewhere of CA/serial numbers it has seen before?
Why does it care? What security risk would be entailed if my browser just ignored the duplicate serial number?

How does my browser know this?

Firefox seems to cache information about certificates which got used, at least until you restart the browser. If you've added an exception because you are using your own (maybe untrusted) CA then it might even have the information in the CA store.

  What security risk would be entailed if my browser just ignored the duplicate serial number?

Revocation information about a certificate issued by a specific CA are checked by serial number only in CRL and OCSP. Thus reusing the same serial number would mean that the same revocation information get applied.


How can I use openssl to decrypt AES-encrypted data using the key and initialization vector? I am attempting to follow the example in this question:
Where is the salt on the OpenSSL AES encryption?
but I'm having some trouble decrypting using the key and initialization vector.

When I encrypt as follows, using "abc" as the passphrase:

$ echo -n Polaco | openssl enc -aes-256-cbc -a -p
enter aes-256-cbc encryption password:
Verifying - enter aes-256-cbc encryption password:
salt=0EEC20170C1B2A76
key=33945888AB044FE34F69289E3186FEA7DB914BF2ED37C2DE123117FB494ACDD8
iv =0C4CAA4A27FE3BFB05399AF217D24357
U2FsdGVkX18O7CAXDBsqdsqiOcaoPpa2OcFAtk2jQGY=

I can decrypt the resulting text using the same passphrase:

$ echo U2FsdGVkX18O7CAXDBsqdsqiOcaoPpa2OcFAtk2jQGY= |  openssl enc -d -a -aes-256-cbc -p
enter aes-256-cbc decryption password:
salt=0EEC20170C1B2A76
key=33945888AB044FE34F69289E3186FEA7DB914BF2ED37C2DE123117FB494ACDD8
iv =0C4CAA4A27FE3BFB05399AF217D24357
Polaco

But when I try to decrypt using the key and initialization vector instead of the passphrase, it fails:

$ echo U2FsdGVkX18O7CAXDBsqdsqiOcaoPpa2OcFAtk2jQGY= |  openssl enc -d -a -aes-256-cbc -p -K 33945888AB044FE34F69289E3186FEA7DB914BF2ED37C2DE123117FB494ACDD8 -iv 0C4CAA4A27FE3BFB05399AF217D24357
salt=1250FC9CF97F0000
key=33945888AB044FE34F69289E3186FEA7DB914BF2ED37C2DE123117FB494ACDD8
iv =0C4CAA4A27FE3BFB05399AF217D24357
bad decrypt
4294956672:error:06065064:digital envelope routines:EVP_DecryptFinal_ex:bad decrypt:evp_enc.c:531:

Note that the salt extracted from the encrypted text is wrong.

I'm using an x86_64 machine, running Cygwin on Windows 10, if it matters.

$ openssl version
OpenSSL 1.0.2n  7 Dec 2017

I feel like I must be missing something basic.

SOLVED by @mvy
The problem was that a salt is randomly generated by default, but when you are specifying the key and iv for decryption, there should not be a salt.  I need to suppress the salt using the -nosalt option.

$ echo -n Polaco | openssl enc -aes-256-cbc -nosalt -p -out /tmp/pol1
enter aes-256-cbc encryption password:
Verifying - enter aes-256-cbc encryption password:
key=900150983CD24FB0D6963F7D28E17F72EA0B31E1087A22BC5394A6636E6ED34B
iv =2EFFA65AF1C5EB20572E2F9896B90FEB

$ openssl enc -d -aes-256-cbc -nosalt -p -in /tmp/pol1 -K 900150983CD24FB0D6963F7D28E17F72EA0B31E1087A22BC5394A6636E6ED34B -iv 2EFFA65AF1C5EB20572E2F9896B90FEB
key=900150983CD24FB0D6963F7D28E17F72EA0B31E1087A22BC5394A6636E6ED34B
iv =2EFFA65AF1C5EB20572E2F9896B90FEB
Polaco

When using the password form of the command, the salt is output at the start of the data stream. When using -a you are encoding the salt into the base64 data.

The Key + IV method does not need salt, and openssl does not remove it from the decoded base64 string.

You should try again by encoding with -nosalt at the start of your encoding command.

Edit: as @forest said in the comments, do not use the password option with -nosalt, it is unsecure and the Key/IV method supposes the pair has been secured securely.

If you need to first use the password method, I suggest that you read about how the salted data is inserted at start of the data stream, and remove it. It might be incompatible with the base64 output.


RFID Transmission from far away Is it possible to trigger a reader from a standard RFID Access Control System? More specifically the badge system commonly used in companies for allowing entry. As in passing an ID to it?  Assuming you have a valid ID you can send to it.

I'm aware there are multiple technologies involved in these type of systems but I'm referring to the more common case (having to place a non-active tag near a reader).

There is a company selling safety equipment using the concept of remote RFID.  Construction person wears an RFID vest and the backhoe has a "card reader" on it and when it beeps the driver knows there is a person behind him etc.  The way RFID works for the most part you just need more copper wire to get a reading from further away.  There are offensive security applications for this.


Shellcode Segfault mid execution? In doing a university assignment, we are launching a shell on a remote server. That's all fine, I have connect back shell code, and when I hardcode the hex attack string into the server and jump to it, it launches. (The stack is executable, so that's not the issue (though it was for a while!))

However, when I pass it (packed using Perl) over the TCP connection, it only executes part of the way. Using gdb, I was able to determine that it set up the socket and connection, but segfaulted at the point it was pushing "/bin/sh" to the stack, specifically, on hitting a \x89 (mov ebx, esp).

Any ideas as to what is happening here?

Thanks!

This isn't really a security question, it's a low-level architecture one. But to get you started, I'd suggest looking in to what a Segmentation Fault actually represents.

Specifically, it happens on an attempt to read or write on a memory address to which the process does not access. The act of copying one register to another does not access memory, so it shouldn't be capable of triggering a segfault. Make sure you're actually performing the operation you think you are. Make sure that the issue isn't actually the previous or next instruction. Finally, another option is look at the location in memory of the EIP. It's probably not the problem, but it may be worth checking what memory is accessed as a side-effect of what's going on.


Should user input be validated for its length in PHP (server side) as a security measure? It is important to note that this user input will undergo validation and sanitation using regex (on the server side in PHP) and then will be inserted into a database. Later it would be shown to other users on the same web site (for example: on a forum).

I'm referring to both a case when I know in advance what length I should expect from the user and a case in which I don't, but I can assume that it is not more than 100 characters.

I'm trying to figure out if there is any security advantages for checking user input length.

I know this differs from language to language, I'm using PHP. Information regarding any other language like Java, .NET, Python etc. would be fine.

As a general rule, you should restrict user input as much as possible, but not more. A field designed to hold the name of towns don't need unrestricted length. But if you cap the length at 25 thinking no names can be longer, you will upset the Welsh.

Shorter input lengths means less space for payloads if you are worried about e.g. SQLi or XSS. It could therefore be seen as defence in depth against these attacks. But if it is your first line of defence, you are in deep trouble... Focus on getting the fundamentals, like prepared statements, right.

Finally, you are right that any restrictions you decide to use must be enforced server side, and not on the client only.


How secure is my encryption security Using Truecrypt? I am using a non-SSD drive: Western Digital Black 1TB. Windows XP (please don't judge why I'm still using XP).

I am using Truecrypt.

Q1. If I were to create a system partition drive C: and 2-3 non-system partition drives D:, E:, F:, etc. using a good password, is my data pretty much secure as long as nobody knows my password? Are there any flaws in my Truecrypt Security Setup?
It shouldn't be less secure than "Whole Disk Encryption" since we are encrypting every partition?

Q2. If I had a weak password, and changed my password to a more secure password, is my data still secure?
(As long as any "adversary" doesn't have the original TC Rescue disk or copy of your original Volume)

Q3.
SSD drives, I believe, are different because if you were to write data on the SSD drive BEFORE you created an encrypted partition, that data may possibly be retrieved.
However, if you created encrypted partitions first, and wrote data to your encrypted SSD partitions AFTER they've been encrypted, is the data safe as long as nobody has the password?

-Source
https://andryou.com/truecrypt/docs/changing-passwords-and-keyfiles.php

Thanks!

EDIT

Mark's Answer is the most specific in terms of what actual real threats So I want to address them. I am NO expert so please correct me if I am wrong.

So in other words, nobody has my keyfiles, copies of my vol or password (which is very secure).... it should still be safe... unless I am missing something

I'm also switching to VeraCrypt but I don't know how secure it is in terms of TRUST and REPUTATION in comparison to Truecrypt (which is very trustworthy in my opinion)

BTW anyone can answer, lot of experts on this forum... I'm no expert :) so would love it if someone can pt out that I'm missing something

#

FINAL EDIT #3- Question for Forest

Forest,
Your answers are SPOT ON and very specific to the questions i've asked. Thank you for listening and answering very specifically.
I believe you answered my question with certainty but I wanted to confirm this with you.

In other words, If Nobody has access to my computer, If my computer has no malware or other vulnerabilities... then....

In regards to the safety of my encrypted data on my non ssd hard drives Black WD Black Caviar 1 TB.

If I were to sell my Hard drive with all my partitions encrypted using TC with a very good password, my data would be pretty much safe and it would be very very hard to access my data without my password.

If My hard drive was stolen, it would be similar.

Is this about correct?

I am using a non-SSD drive: Western Digital Black 1TB. Windows XP (please don't judge why I'm still using XP).

OK, I won't judge, but I will say that Windows XP (or any other equally vulnerable operating system) will only provide you with data at rest security. That is, when the system is powered off, the encryption is as secure as the underlying encryption and the key. An attacker with physical or network access to the computer can violate integrity and confidentiality without needing to break the encryption itself.

Q1. If I were to create a system partition drive C: and 2-3 non-system partition drives D:, E:, F:, etc. using a good password, is my data pretty much secure as long as nobody knows my password? Are there any flaws in my Truecrypt Security Setup? It shouldn't be less secure than "Whole Disk Encryption" since we are encrypting every partition?

If you define secure as providing data at rest security, then yes, it is as secure as your password. Do note that the presence of a hidden volume may be revealed due to a bug in TrueCrypt. Of course, even if you encrypt every partition, the bootloader itself still must be unencrypted. This makes it vulnerable to "evil maid attacks", where someone with the ability to write to privileged locations on the disk replaces the bootloader with a malicious version to steal your password. This requires the attacker have, e.g., physical or privileged local access, and it will only violate confidentiality at the next reboot. Assuming no one has tampered with your disk and your password is strong, it is secure.

Q2. If I had a weak password, and changed my password to a more secure password, is my data still secure? (As long as any "adversary" doesn't have the original TC Rescue disk or copy of your original Volume)

Yes it is. The way TrueCrypt (and many other disk encryption utilities that encrypt large amounts of data) work is by creating a master key and encrypting the drive with it. This master key is generated completely randomly and is not influenced by your password choice. The master key is then encrypted with your password, and the encrypted master key is stored on the disk. If your password is weak, it becomes easier to decrypt the master key, and then use it to decrypt the rest of the drive. When you change your password, you are not changing the master key itself. Rather, you are decrypting it with your weak password, then re-encrypting it with your new, strong password. The newly-encrypted master key is written over the previous, weakly-encrypted master key, making it unrecoverable. As long as no copies of this previous, weakly-encrypted master key are recoverable (through the recovery disk as you mentioned, or through SSD wear leveling), it cannot be retrieved.

Q3. SSD drives, I believe, are different because if you were to write data on the SSD drive BEFORE you created an encrypted partition, that data may possibly be retrieved. However, if you created encrypted partitions first, and wrote data to your encrypted SSD partitions AFTER they've been encrypted, is the data safe as long as nobody has the password?

The thing that makes SSDs a bit strange for encryption is wear leveling, which makes it impossible to intentionally overwrite specific data. The SSD's internal controller manages all writes and does not let the operating system control it directly. While you are correct in that there is no issue with writing to an encrypted partition on an SSD, the real issue is different. There are two issues, actually:

Wear leveling prevents the operating system from overwriting specific data, causing previously-written contents to persist. This can be an issue if you set a weak password and later switch to a stronger one. The VeraCrypt documentation explains this. TRIM, if enabled, is a way to tell the SSD controller to securely overwrite and zero sectors that are no longer in use.
TRIM can reveal to an observer what sectors are unused. This is unfortunate because TRIM can make the former issue less problematic. TRIM is designed to improve performance and allows secure deletion of unused data. While not an obvious issue (after all, the used sectors are still encrypted, and the unused ones are just zeros), it does give away the structure of your filesystem. This is described more in an excellent blog post.

Do I have to Turn on AES-NI? or is it default? so am I secure with default CPU settings or do I have to do something

AES-NI is a set of CPU instructions for doing AES encryption in hardware. It is designed to improve the performance of encryption, but it also has the benefit of creating side-channel resistance. A side-channel attack against AES is usually a cache attack. This involves running a malicious program on your computer that listens very closely to nanosecond-level delays when accessing data in the CPU cache in clever ways to determine what the AES key is. AES-NI prevents this by not using the cache. Since you say you are using Windows XP, you hopefully are not in a situation where a malicious process is in the position to run on your computer, or it has far better ways to get your key than a side-channel attack. In other words, a side-channel attack is an active attack against running encryption, but it cannot violate data at rest security.
TrueCrypt will use AES-NI by default if it is available.

I'm also switching to VeraCrypt but I don't know how secure it is in terms of TRUST and REPUTATION in comparison to Truecrypt (which is very trustworthy in my opinion)

It is based directly off of TrueCrypt and, like the former, has been audited. The source code is entirely open source. While some design decisions it has made are, in my opinion, kind of silly, the core of VeraCrypt is both secure and trustworthy. Continuing to use TrueCrypt opens you up to several unfixed issues which, of course, were not fixed since there are no more developers to fix them. This includes code execution vulnerabilities and some minor weaknesses in the crypto (bad random number generation, for example). Additionally, TrueCrypt uses a very low number of PBKDF2 iterations (usually 1000). Each iteration makes it harder to crack a password by making it take longer to derive the key from the plain password. VeraCrypt uses a variable number of iterations, often exceeding 100,000. For a very strong password, this does not matter.
To summarize, you are using a non-SSD drive on an insecure operating system but are using a strong password. This provides you with data at rest security. No one, should they get their hands on your disk, will be able to decrypt the contents without the password. The only way they could obtain the password is by attacking your computer with malware or exploits, or by tampering with your disk so that, next time you boot it up, you boot into a malicious bootloader. As long as your threat model only cares about data at rest security (e.g. you're using this on an airgapped PC), you should be fine.


What's the risk if I accidently type my password into a username field in a website? On websites that separate the screens where username and password are entered, such as GMail, it is possible that the users type the password in the username field because the username is sometimes suggested automatically based on the browsing history.

In that situation, what are the risks if the user types (and press Enter) their password in the username field?

Reply to "duplicate" flag

I don't see how the questions about typing a password into a username field in a website and in Windows logon can be duplicate one of the other. Questions are duplicate if they ask the same thing, not if the answers happen to be the same.

If the answers happened to be the same, I believe the proper way to answer this would be: "The risks are the same as when the password is typed on Windows logon. Please refer to this question (link to the other question)".

Anyway, the answer to the duplicated question doesn't even answer the present question, as that refers to eventvwr.msc and Failure Auditing in Windows.

The greatest risk is if the site logs login attempts based on the username that a user enters, rather than the account.  Your password will then be displayed in cleartext in the logs, which may be leaked at some future time.

In most cases, nothing risky will happen.  The site already has access to your cleartext password while you're logging on, whether they store it securely or not, so sending your password to that site in a different form field wouldn't have consequences, unless other users can see what you've entered into that field.

The normal best practices apply, of course: Never reuse your password across different sites. The site owner might be malicious, and even large, trustworthy, highly audited multinational companies will leak customer data at alarming rates.  Your information has already been leaked.

This way, if you don't reuse any passwords, and use a password manager to generate truly random, unique passwords for each site, when you suspect that a password might leak, such as being logged when it shouldn't after you put it into the wrong form field, then you can update the password once on that site only, and your risks will be mitigated.


SMS: Apple has detected multiple failed login attempts I have just got a SMS message (text message) on my phone saying:

  Apple has detected multiple failed login attempts

Given I don't have (and have never had) an iPhone, I expect it is some sort of scam. However scammers are not well known for using a messaging system that they have to pay for and that is traceable to the sender.

So

Should I report it to anyone (I am in the UK)?
How are they getting round the networks being able to trace the phone that sent the SMS message?

This could be sent from a hacked phone server, hacked phone account for sending sms, or from a service that has unlimited sms.

Is this the literal message? Is this all that was in the message? If I google for this (with quotes) I don't get a result back.

Do you see a number or name? Google it and post it here.