GPG key expired on mykeyring, but still valid on keyserver

Have you tried pushing your updated key to the keyserver?  The main reason that your copy of the key and the one on a keyserver would differ is that you changed the expiration date of your key on your local machine after pushing it to the keyserver.  See https://www.gnupg.org/gph/en/manual/x457.html for help if you need to update a key.  Once you update the key on the keyserver, the keyserver should begin distributing the updated key to users looking for your key.

Alternatively, if you no longer wish to use that key, you could revoke the key and publish a revocation certificate to the keyserver.


filtering content in Content disposition header

If you need non-Latin names: You must use RFC 2047, RFC 2231, or URL-style percent encoding in a browser-dependent manner. Make sure to filter out control characters (0x00–0x1F) and escape any semicolons, backslashes, and quotes.

Don't even go there. Hidden behind the words "browser-dependent" is a set of inconsistent and incomplete escaping rules that varies wildly across browsers. Sniffing the browser type and serving up a different encoding for different cases is not really feasible at all... even if you did so (and handled Vary/cache properly to match), there are characters that are impossible to encode for each of the browsers.

  Which are the characters meant to be URL percent encoded?

On IE, ;, " and anything non-ASCII. On any other browser, percent encoding in Content-Disposition is not effective.

  By "escaping semicolons, backslashes, and quotes", is escaping using backslashes meant?

Yes, but only Opera supports this properly IIRC.

Eventually the rules of RFC 6266 will fix this grisly mess, but support isn't there yet. If you want arbitrary Unicode characters in the download filename, the only reliable way of doing it is to put the fake filename in a trailing part of the URL path, UTF-8-URL-encoded (IRI-style) eg.:

http://www.example.com/download.cgi/h%c3%a9llo%20%e6%97%a5%e6%9c%ac.dat

results in download filename héllo 日本.dat.


This exploit is only possible in old versions of Internet Explorer. Modern browsers will not auto detect the encoding as UTF-7.

OWASP:-

  This does not work in any modern browser without changing the encoding type which is why it is marked as completely unsupported.

Wikipedia:-

  To mitigate this problem systems should perform decoding before validation and should avoid attempting to autodetect UTF-7.
  Older versions of Internet Explorer can be tricked into interpreting the page as UTF-7.


How can I protect this PHP code against XSS?

Use htmlentities just on the user-supplied data:

<?php
$ip = $_SERVER['REMOTE_ADDR'];
$escaped_ip = htmlentities($ip);
echo ("
Your IP: $escaped_ip
");

If you are writing a real application, it would be better to use some template language that escapes values by default. This makes it easier for the developer to do it correctly, making it more secure.


It is possibly an attempt at Bayesian Poisoning of your spam filter. Spam filters work by analysing words in the email and assigning them a spam value. One form of Bayesian Poisoning is to send an innocuous email that contains mostly "good" words and one or two "bad" words. The spam filter will see the message as not spam and over time it can be trained to assign these "bad" words a lower spam value - which will allow more spam though.

See also How does Bayesian poisoning work?


Protect against malicious client with key derivation function (PBKDF2)?

If the salt used for PBKDF2 is of non-trivial length, say 128 bits, and the salt is stored with the form ID on the server (only), then this will allow you to check whether the form ID has been tampered with.  There must be a secret component to the hash because of Kerckhoffs' principle, AKA Shannon's maxim.  In this case, the salt, stored only on the server, is the secret.


What is the endgame of a site like this?

Without analysing the code on the site, the idea could simply be to see what types of material users will click on. The "endgame" is to create profiles of you or people like you to determine what will interest you enough to click on things.

Is this malicious? It doesn't have to be. It could be for generating commercial advertising profiles or for more nefarious purposes like political/ideological profiling for the new game of cultural influencing.

I created a phishing platform that would send a variety of different types of phishing emails to a user to see what the user would click on. It would figure out what elements of the phish would trigger the user to click. Then it would use that data to compose its own emails. This could be a similar process for ads. The fact that it seems auto-generated would support that hypothesis.


How can companies verify that a national security letter is real?

This doesn't contain an answer about how to verify that it's legit but this does answer other questions you probably have about it

EFF - NSL Letters

I would think that the portion containing the gag, to not tell anyone about it, doesn't include barring you from contacting the agency that issued the NSL to you, for further details.  For example, if it came from the FBI, you may be able to contact the FBI for further information about it.


Login to one site using other site's credentials

Sites like Google and Facebook implement protocols such as OAuth to accomplish what you describe and what is known as Delegated Authorization.

In short, the answer to your question is no. Sites that allow you to sign in with your other accounts never see your account credentials. In simple terms, Google / Facebook are creating a limited use token that links you to your account that may be used to access some of your information on Google / Facebook. Typically, it goes like this:

The client (other website) obtains a token from the server (Google for Example)
The client requests authorization from the Resource Owner (you)
The resource owner validates the request and grants authorization.
The client exchanges the request token for an access token.

There are different methods (flows) that achieve this same principle. You can read more about it here:

http://oauthlib.readthedocs.org/en/latest/oauth2/grants/grants.html


Can remote control still take place during Windows session lock?

TeamViewer works like physical access to the machine. The remote user would still have to log in to the Windows session, if you locked the machine.
I think it can still transfer files, if I'm not mistaken. So you wouldn't be 'safe' at all. But it would be a little less convenient for the bad guy.
So locking your machine wouldn't block the attacker from connecting remotely, but it would stop him from using your active user session the way you described it.


Where are historical data for the CIS Alert Level?

It seems that this kind of information is now only available for members of MS-ISAC. If you're a U.S. SLTT government entity, you can submit for a free membership. But, if not, unfortunately there isn't any resource for alert history.

As an alternative, you can track the advisory page of MS-ISAC for last years track (~3 years) or subscribe to their newsletter.


Is there a security method for data transfer that hides the sender?

There are several options:

burn the data to a CD-ROM and mail it while not giving a proper sender address
use anonymizing tools like Tor, anonymous mailers etc
work from an internet kiosk, open hotspot or similar

Of course there are often ways to at least narrow down possible senders based on the data they send (who has access), writing style etc.


Why doesn't the HTTP/2 spec require TLS?

There is no technical reason to limit HTTP/2 to TLS. Communication without TLS has its technical use, no matter if this is unencrypted traffic or if the traffic is encrypted by other means (VPN etc).

Restricting HTTP/2 to TLS in the standard would bind the use of the HTTP/2 protocol to the use of TLS for political(*) reasons only. Such bindings for non-technical reasons are usually avoided: If you look for example at the RFC for HTTP/1.1 they explicitly keep the transport layer open, i.e. acknowledge that HTTP/1.1 is usually used on top of TCP/IP but might be used on top of other protocols (RFC2616, section 1.4).

Thus while one might think that there was some evil lobbying I think that simply the majority found that standards should be a place for technical details but not  for political(*) statements.

An interesting mailing thread in this context is Mandatory encryption is theater on the IETF HTTP WG mailing list in 2013 which highlights the diversity of opinions among the technical users. And is also visible from this thread that this is not a lobbying from some ISP or similar but that there are technical reasons to not bind HTTP/2 too much to TLS, because TLS is known to be not the optimal solution for the diversity of authentication, encryption and privacy problems: in some cases you want to have better protection than TLS can offer and in other cases you don't need the protection but the overhead of TLS is bothering you.

(*) To make more clear what I consider political: It's less geo-politics or company-politics but mostly personal opinions influenced by these larger politics. This leads to arguments based on the personal view of how the world should work and not based on technical reasons. Sometimes this political arguments are even blind to technical arguments because they don't fit into the  personal view of the world. This includes the argumentation that all use cases require privacy (which TLS does not offer fully anyway), that small systems without large resources should just grow up or not use HTTP, that caching is an unimportant thing which does not need to be considered (i.e. we have lots of bandwidth and don't care if others don't) etc.


SQL injection vulnerability identification using URL's GET param

1)
If anything on the page chances, there is likely something wrong, and probably SQLi. However, if it's a Database-error, you have a big chance of it being SQLi-vulnerable.
A white page on the other hand ain't necessary a guarantee it's vulnerable. Maybe the 'news article' or whatever wasn't found and the website just returns a blank page.

Also, needed to mention that there is a difference between a Database-error and a WAF-error, HTTP-error,... The latter two don't necessarily mean a SQLi-vulnerability though.

2)
Yes, also this shouldn't be accepted by the server-side code. And you can be pretty sure a SQLi-vulnerability is going on.


A security advisory about the matter was posted on the Django blog:

This issue does not affect Django directly, but will affect most users of Django.
Any web server which is serving traffic over a CGI or CGI-like interface (including WSGI) should upgrade its version of Bash immediately.


I've been working on something similar for signing messages. The short answer is: it's only supported in Chrome, but the future is not bright.

You can do it using the Filesystem API. However, the problem is: this is not getting standardized by the w3c, support for it in any browsers other than chrome doesn't work, and, it's wholly possible that a rogue script could access the filesystem API and steal your key.

I ultimately abandoned the project. You would be wise to reconsider what you're working on. CryptoCat already solved the secure browser chat problem...

EDIT:

Seems crypto cat was re-written in 2016 and now has PC based versions. There is a crypto-cat legacy repo that appears to have the original CryptoCat code.


You can't feasibly obtain an AES key just by being able to encrypt and decrypt data of your choice. To broaden it a bit, no secure cipher lets you feasibly obtain the key, even if you can encrypt and decrypt as much data as you'd like. That's a combination of what's known as a chosen-plaintext attack and a chosen-ciphertext attack, and every modern cipher is designed to be secure against those. The only way to realistically obtain the key is through reverse-engineering; I'd focus all your efforts on that, not on trying attacks AES is designed to resist.


What is the difference between YARA and CLAMAV?

Yara is a tool which is used to write a rule for detection of malwares whereas CLAMAV is antivirus that has predefined rulesets that is used to detect the malicious software or malware. Today there are various antivirus engines use yara rules to detect malwares. YARA provides simple and efficient way of writing rules. It is more popular because of it can be used through yara-python library. So if you want build your own malware detection framework so you can use it efficiently.


cd-rom distro --- plus additional validation

The first truth of Information Security is that there are some people you have to trust. Without that truth the whole discipline of Information Security turns into paranoid free-fall. May I suggest trusting your colleagues?

In lieu of that, the best way to protect your "attack surfaces" is to

Backup to multiple sources; some of which are write-once audit servers.
Lockdown employee access with two-factor authentication
Turn the web server into a virtual instance booted from a recoverable ghost image. Our peers at Server Fault can explain how.
Full disk encryption if you want the data unavailable if someone physically steals your server.
Install Panopticon-style video camera surveillance.


How to convert SSL Certificate for mobile app?

Can you confirm what you're actually asking here;

Is it that you have two domain names IE;

1 - Networkguys001-website.co.uk

2 - Networkguys001-mobileapp.co.uk

and you want to have 1 certificate which secures both domains?

If this is the case then what type of certificate did you buy from Digicert, I've included a list below;

WildCard SSL Certificates,
UC (SAN) Certificate,
Extended Validation SSL,
SSL Plus Certificate.

Typically you'd could buy a wildcard which covers; *.Networkguy.com

1 - www.Networkguy.com <- Website

2 - Mobile.Networkguy.com <-URL for Mobile

However it depends how your current domains are structured and if they're hard coded and distributed already.

Anyhow if you answer the questions I'm sure a mobile


Does a basic sudo-less Linux user or a sudo user but with a password for sudo offer enough security against webpages exploits?

Security is a question of layers.

The non-su user with the least elevated privileges is one layer to reduce attacks.

A continuously patched browser which makes every effort to minimize system risk through sandboxing and other techniques is the next layer.

A hardened OS that encapsulates the browser and prevents stack/heap/privilege based attacks is the next layer.

A content filtering system (either in the browser, on the machine, or at the gateway level) is the next layer.

A breakdown at the browser or OS level would circumvent everything you have tried to achieve by reducing privilege level for the user.


Is it possible to reverse a hashed password?

No. Hashing is not reversible.
What is usually referred to as "cracking a hash" is to throw lots and lots of strings on the hash function and comparing the output with the list of hashes (a.k.a. "brute force").


What is the most appropriate way to notify/request permission from an ISP related to white-hat security testing?

I have never asked for permission in advance (that I can recall), but I can say clients on many occasions have reported IP addresses under my control to be attacking them.
For example:

TOS Violation - Malicious Activity
We have received a report of malicious activity originating from an IP address assigned to (redacted). Please investigate this complaint and update this ticket within 24 hours to avoid a disruption in service.

Most often my clients simply neglected to check the list of authorized IP addresses I mentioned I may use during testing.
On every occasion, after answering a TOS violation, the ISP goes to verify with the target that the activity is authorized and all is good.
Note:  Amazon now makes it easy to ask for permission in advance:  http://aws.amazon.com/security/penetration-testing/ (I have heard others do as well now)


Why are the domains https.lk , ftp.lk and http.lk restricted on the Sri Lanka domain registry

TLDs (top level domains) are allowed to have certain restrictions based on location, the type of content, and the domain names.

It is not surprising that they'd block it to avoid confusion on the domain name's owner which would appear to many as being the same as .lk.


Can a hacker compromise the system if he can steal one of the factors of the 2FA?

I read an article saying that smartcards used as a 2FA is still susceptible to attacks such as MITM attack?

I interpret the relevant parts of this article as follows:

A hacker could mirror the original web site which asks for password and 2FA token and just forward the credentials you've entered to the original site, then doing whatever he wants with the now logged in session.
A 2FA authentication might be done only against the local system and then the result (in form of some authentication token) is used to authenticate against a remote system, then this token could be stolen.

To address the first issue: This is true if the 2FA is only some kind of token which you enter. If instead the smartcard has a client certificate which is used for mutual authentication within a TLS connection, then this can neither be stolen when connecting to a fake website nor can the authentication be forwarded to the original site since the attacker does not have access to the private key stored on the smartcard.

And for the second issue: If the full authentication is only done to the local machine and then the local machine provides some authentication against the remote machine then this remote machine can of course not check if 2FA is valid and must simply trust the local machine. Thus the question is not only how to do you authenticate but also against whom you authenticate: a local machine or a remote system. Of course, since no 2FA information are send to the remote system in the first place there is no MITM of 2FA done. And yes, a hacker could intercept the authentication token unless the transfer of the token is protected against MITM, for example within a TLS connection with mutual authentication between the machines.

In other words: smartcards are by themselves are not affected by MITM. But they might be used in a way which makes MITM still possible or which makes it ignore the second faktor. But using smartcards for mutual authentication within a TLS connection is considered safe even if the web site you connect to was not the correct one.


Mostly yes, any CA in your trusted root, (or subordinates) can issue a cert for any DNS name.

Name constraints and Enhanced Key Usage can be used to mitigate this, but they aren't enforced everywhere.

DANE, Certificate Pinning, and Certificate transparency are a few projects that help protect from this risk.


With SAP_ALL access rights, can someone run an executable on the SAP Netweaver ABAP server?

Yes, SAP_ALL gives you all you need to get a shell as <SID>ADM on the box. First, you can run report RSBDCOS0 which gives you OS code execution right away. Second, you can make use of the sapxpg mechanism which also executes OS programs. As SAP_ALL user, you can also change the config so that RCE is possible over the network.

Both mechanisms allow you to add another SAP_ALL user for later use by directly inserting 2 lines into USR02 using a DB client which escapes all SAP-internal logging.


There's two different concepts at play here:

You Firefox Sync account
The master password (the login manager)

Number 2 is independent of whether you use Sync or not. It's a password protection for the local storage of saved passwords.

It used to be that when you had a master password on a device, Sync would not synchronize saved passwords on that device.

This was changed around Firefox 34. Apparently now when your MP is unlocked it will sync the saved passwords to your account. When it's not unlocked it will silently do nothing unless you explicitly ask it to "Sync Now".

So think about the master password as a local-only protection, the synced data is already protected by other means on Firefox Sync's servers (your account credentials).

As pointed out by @Ben:

  It's worth noting explicitly here that the synced passwords are not
  just "protected" with your sync password; it's encrypted using them.
  So be sure the sync password is strong! The other thing that means is
  that you will lose any synced passwords if you reset your sync
  password via "forgot my password", because Mozilla cannot decrypt them
  without your sync password. But the assumption in that case is, that
  you still have your local copy, so you should be OK

This applies to all sync data, not just passwords, and is thoroughly documented at Mozilla's GitHub.

If you want you can disable saved password sync from Sync's options.


There is some information and many pointers on this page. The common idea is that Firewire allows DMA: the plugged device can read and write physical memory at will (this allows fast data transfer without clogging the CPU; it is very useful for hard disks and fast network interfaces). For Firewire, some mitigation can be achieved by removing or nerfing the Firewire support on the OS (most Firewire controller require the OS to do a bit of initialization job, and we remove that part -- but there could exist Firewire controllers which will accept device-initiated DMA even if the OS does nothing, so it is hard to know if actual protection is achieved that way).

PCMCIA/PC Card/CardBus/ExpressCard are successive names for a peripheral standard which is, basically, a PCI (or PCI Express) bus with safe hotplug. DMA is consubstantial to PCI, so there is little defense against an attacker who has physical access to such a port.

Generally speaking, if the attacker can physically access the machine, you are doomed.


No, you shouldn't be worried, especially not at the rate of HEAD HTTP requests that you're quoting. One such request every half an hour on average is really not much. Basically, HEAD requests do what it says on the box, that is, your web server will only return response headers and will not attach to it the complete response body. This can be useful to lower bandwidth requirements for simple tasks of e.g. establishing response code for requested location, client cache validation, and so on. That can then be used to either establish that your web server is responding, or if the requested location is still available, not re-send contents that weren't changed in the mean time and are already locally cached by the client,... depending on your server's response HTTP status code and header contents.

Now, these requests can be rather frequent and sometimes a bit annoying in quantity, but they're technically for your server better in terms of consuming its resources, since a well written web host can process such requests faster and consume less upload bandwidth to send back a response, than if it had to process and include in its response a complete document. With larger media files, this gets even more apparent. So I wouldn't advise to block such requests in your web server configuration, and if they make your server's log files less readable, I recommend you pipe such requests into a separate log file.

As far as what's returned in these headers, there's nothing much different in them that with the normal GET requests, with the exception that the content length will be obviously smaller. And there is no reason to think that increase in HEAD HTTP requests is some form of a DOS attack on your server, since it would take the same effort for the attacker to send GET requests, while at the same time exhaust your server's resources much faster. The only case when HEAD would do that faster than GET is if you don't rate limit or block by other means (e.g.request IP) the former, but you rate limit or filter the latter and a few other common HTTP request types like e.g. POST, which would be a case of misconfiguration and isn't really frequent. Do make sure you don't unwittingly disable any such filtering in your configuration for less common request methods tho, just to be sure.

So if you should block HEAD requests is up to you, but I wouldn't bother. There are other HTTP request types that are a lot more worrying, especially if you don't even have any use for them on your host, for example TRACE, SEARCH,OPTIONS,... And it is always a good practice to disable response to all HTTP request methods that your server software doesn't have any use for. For example, this is from my Apache config:

RewriteCond %{REQUEST_METHOD} ^(TRACE|SEARCH|TRACK|OPTIONS|PUT|QUIT|CONNECT|DELETE|PATCH|DEBUG|PROPFIND|PROPPATCH|MKCOL|COPY|MOVE|LOCK|UNLOCK)
RewriteRule .* - [F]

This assures that none of the methods listed are served (request forwarded from the web server software to the application handling these requests and processing them) and the web server immediately denies them by returning a 403 Forbidden status code to the client. Do note though that your web applications might be written to require some of the HTTP methods that I block in my configuration, this example is not meant to be copied directly and can break functionality of your web host, if not used with caution!


Restrict access to public URL many times

you can try implementing Throttling  in your code.
You can also use a Proxy Firewall or LoadBalancer to limit the rate of requests.

There are open-source proxies like HAProxy and Nginx which can be used.
there are also factory made proxy firewalls available.

There are Cloud Proxies like Cloudflare which can be used.(my money is on these)
If you are running your Web Application in a Public Cloud, your cloud provider may also provide some security measures .
some kind of Caching may also help, depending on the scenario. refer HTTP-Caching


How much of a security risk would the apps on my iPhone pose if I did my banking on iPhone?

iOS does indeed sandbox apps from one another. Unless some of your installed apps had special exceptions to the usual list of permitted capabilities (permissions), they cannot read or write any files in your banking app, nor can they interfere with its execution in any way.

With that said, there are a few exceptions to be aware of:

Custom keyboards could potentially capture sensitive data. I don't know what the state of third-party keyboards currently is on iOS, but on Android it's been a concern for some time. Apps should be able to force the user to use the standard keyboard for sensitive content (credentials, etc.).
Local network connections (typically using loopback / 127.0.0.1) are not secure. An app that talks to itself or to another trusted app over the network this way could potentially be attacked at either end by a malicious app running at the same time (that is, the malicious app could launch its own server on the same port and try to get the victim to talk to it, or could make requests from its own client to the legitimate server and try to compromise the process or extract information from it). The insecurity of this design pattern has been known for years, and there are well-known superior options for most use cases, but people insist on doing this anyhow (partially because it's one of the only ways for a web page in the browser app to establish bi-directional communication with a store app). Hopefully your bank isn't doing anything like this - or if it is, it's hardened the channel very carefully - but it it's a risk.
Apps that use root privileges on jailbroken devices, or that use the kind of privilege-escalation bugs used for jailbreaking, are able to ignore their sandbox and interact with any processes or files on the device. In this way, they're more like a local app running as Admin/root on a PC. Obviously, if such an app is malicious or compromised, there's nothing you can do safely on that device.

Apple does perform a security review of every app before they approve it for the store. This review process has known holes - even manual line-by-line review wouldn't necessarily catch everything, and Apple can't afford that kind of effort so it relies heavily on automated tools that can be tricked - but for the most part there's extremely little malware in the iOS App Store.


Full disclosure: I work for Voltage Security.  I think it's better to state that up-front, rather than give you some sales spiel and then "accidentally" point you to our web site.  While this is not a company-sponsored response in any way, I freely admit that my views are not unbiased. I will try to minimize the leakage into this response, but please read with the appropriate degree of skepticism.
The fundamental issue with asymmetric encryption schemes is not the encryption, but the key management.  So what distinguishes PKI systems is not the security of the encryption, which is identical, but the ease of user provisioning, deletion, and general system management.
So, the questions I would ask of a vendor of asymmetric encryption are:

What is the process for bringing a new recipient of encrypted data in to the system?
How are the private keys stored, protected and backed up?
How are credentials managed?
How are name changes handled?(e.g. someone gets married and changes their name & system logon: what, if any, are the impacts?)
How can encrypted data be scanned by data loss prevention devices to ensure insiders are not using the encryption facility as a way to smuggle data out of the company?

EDIT
(this is the stuff I left out originally, because it felt too sales-y)
Reasons for asking the questions above:

Most PKI systems require the recipient to create a public / private key pair before any data can be sent to them.  This inhibits ad-hoc use of the system, in which people can encrypt for any recipient.
If a private key is lost, the data encrypted with the corresponding public key is lost.  End of story.  Any serious PKI system will have some mechanism for retrieving lost private keys.  If this is a database of keys, then you need to think about how this is protected, and ensure that it is backed up frequently.  Also consider replication if the solution has to exist in multiple data centers for high availability.
This is a easy one: users have to provide some sort of authentication credentials to get access to the private keys.  Ask how this can be integrated into existing authentication methods.
Imagine that Mary Jones gets married (or divorced) and becomes Mary Smith.  Using the credentials for "Mary Smith", she needs to be able to access data that had been previously encrypted for "Mary Jones".  The PKI system should handle this case gracefully.  The alternative is finding all the data encrypted for "Mary Jones", decrypting it and then re-encrypting it for "Mary Smith".  Yuck.
Fundamentally, the DLP device needs to be able to access the plaintext of any encrypted data.  Ask how this can be achieved.


Is dual-booting an OS more or less secure than running a virtual machine?

Answer first, then why: A virtual machine can be more secure.

From a practical standpoint, there exists code and malware that can infect both boot partitions, BIOS, and also hardware devices.  So, a VM has slightly more advantages in a reduced attack surface from a generic point of view - potential VM hopping code is the largest one specific to the VM.  This code is likely to be specific to the type of VM being employed such as the recent http://www.kb.cert.org/vuls/id/649219 issue.  Note it required a specific virtual machine (kvm or xen), ring, etc.

So, from the perspective of hostile code, virtualized is more secure.

Approaching from the network angle, many users of virtualization solutions have more flexibility at the network level via NAT within NAT, PAT, or other features an OS may not native support, or rolling their own enhanced security through use of the VMs.  It is fairly trivial to enhance a secure posture via using a specific VM to inspect all traffic i/o with virtualization.

So, from the perspective of network security, virtualized is more secure.

Onto guest operations.  The beauty of cloning operating systems in second...Depending on the type of virtualization solution being employed, a powered off VM can be patched transparently without action by the user.  It is trivial to take a general purpose VM, and lock it down using various hardening guides to where there is minimal functionality except from specific applications. VMs make it easier to perform extreme levels of hardening such as performing least privilege on certificate trust stores (e.g. I delete most certificates from commercial CAs except for ones I am using)  These type of activities can be much faster with a VM due to the ability to snapshot and recover from catastrophic changes.  Furthermore, a VM in entirety can easily be packaged up into a file and saved somewhere, on a USB, etc.  Also, when you think of compromises, realize that in virtualization, a compromise can be much less privileged than regularly.  In a type 1 hypervisor for example, it is the hypervisor itself that is the most privileged instance on the computer..  Increasing levels of hoops for an attacker.  It can also be used to grant developers administrative/root access, without granting said developer domain admins, or privileges on the corporate LDAP.

So, from the perspective of guest operations, virtualized is more secure.

However, I'm going to focus on the premise for a second - that virtualized and booted up native type OSes are either-or choices.  They aren't, as you can boot a virtualized OS using 3rd party solutions as if it was a dual boot option.  Software like vboot enables VHD/VMDK/VDI/Raw format booting.

As far as types of virtualization go, there are a few that are applicable to this case.  Those being Type 1 virtualization (bare metal), Type 2 virtualization (Hosted OS) and I  consider partial, operating system & paravirtualization out of scope. The leading x86 type 1 virtualization solution, VMware vsphere hypervisor, uses a microkernel approach with a minimal attack surface.  Type 2 virtualization have bigger attack surfaces since they rely on a full underlying operating system.  So, Theo's comments about full operating systems is incorrect when applied to VMware.

Here is some VMware propaganda on the topic

http://www.vmware.com/technical-resources/security/overview.html

Of course, security is most often a tradeoff between usability and security.  It is important to consider a threat situation that a user is likely to encounter, and who will deploy resources against you to attack you.  If you are a nation-state or bank you need extensive protections.  Companies, more.  Individual users of little notoriety - good enough protections.  Keep in mind that a good security solution protects you enough, but does not negatively impact usability to the extent of being a hindrance.  Overall risk management is a different topic, worthy of review elsewhere.

I didn't talk about more exotic security approaches, such as thin clients that could be used to expand upon virtualization security by further reducing attack surfaces, or TPM lockdown in conjunction with a type 1 hypervisor.


Process of finding device hostnames on LAN

It would be useful to know what operating system you're using, also some idea of the network topology.

Some devices announce themselves using mDNS or perhaps the network supports reverse DNS lookup with clients providing their hostnames during DHCP exchanges.

If DNS is available on the network, nslookup is available on most platforms nslookup xxx.xxx.xxx.xxx

Then there is NetBIOS, on Windows you could try nbtstat -A xxx.xxx.xxx.xxx

Also ARP might be useful arp -a


Performing an attack on an https:// address without change of URL would require :

Certificate impersonation (someone has stolen private keys of the site) + DNS poisoning
I think it would be possible to do it also by tampering the hosts file on someone's system, but would still require a valid certificate.

To ensure not being hijacked this way, always be certain that your browser is up to date and ensure certificates are up to date too. Certificate can be rendered invalid and the CRL (Certificate Revocation List) should be checked whenever you have to use a certificate (via OCSP  -Online Certificate Status Protocol - or so). I do not remember how browsers handle this type of request.


What information should I collect when a user performs an action on a website?

I will assume the example that you mentioned:

IP at the moment of the action.

This is good

Exact date.

Also good if you add the time as well

The values before and after the transaction.

This is also good but I would probably detail it and add some more info as:

Transaction ID
Quantity sent
Type of transaction
Sender and Receiver (including the accounts id, for example)

Login credentials.

This is an absolutely NONO for many reasons:

If you mention credentials I assume that you mean cleartext password, which would imply that they are not hashing psw -> BIG NO
The idea of logging is to keep a track of the user actions. If an admin is checking logs, why would he need the credentials of the account? Also, take into account that your app should always follow the least privilege principle

In the end what we want to achieve with logging is to ensure non-repudiation. It would not make a lot of sense to add credentials in there. Just imagine how catastrophic would be if that page would be exposed through a XSS or something similar!


How can I prevent API bot automation by a legitimate user?

If the security controls exist only on the client, you have no control over the security controls. That's an intractable problem that appears in all corners of security. If your security model presupposes that a device that the user owns will not be manipulated, then your security model is based upon an incorrect assumption.
You've mentioned a few approaches to making it more difficult, but none of them offer concrete protection because your game logic is completely in the control of a malicious user. This comes up in game cheating all the time, and the only concrete solution is a server authoritative model. In absolute terms, this means running the game logic on the server, not the client.
A fully server-authoritative system is not always feasible. Consider, for example, a first-person shooter game. If the server was responsible for the entire game, including rendering the images that the user sees, it would be unplayable due to latency issues. The first obvious concession is that the game must be rendered on the client-side, but this already opens up avenues for exploitation, such as wallhacking. The work involved with developing a secure game model lies primarily in coming up with a reasonable compromise between user experience, development cost, and security. What you'll likely arrive at is a combination of concrete controls, and compensating controls. The concrete controls enforce certain behaviours and capabilities absolutely, and the compensating controls make it harder to exploit the gaps in between.
You mentioned questions in one of your comments. This type of game mechanic is much more easily adaptable into a server-authoritative model. The game asks the server for a question, the player answers the question, and the answer is sent back to the server for verification. The answer never leaves the server, and the server has authority over whether or not the question was answered correctly, which makes it much harder to abuse. You can apply reasonable time limits on how long a user can take to answer the question, as well as rate limits to prevent obvious automation.
In games where the player moves about a space, e.g. a platformer or RPG, you can enforce that the game cannot progress beyond a certain stage without reaching certain milestones. The server can reject a game completion request if the client has not sent the prerequisite milestone notifications, and minimum timings can be enforced between each notification.
In more interactive game designs (e.g. MMOs or FPS) the server keeps track of player positions in realtime, and rejects actions that are not possible, such as changing position too quickly (speedhacking), interacting with an object that is too far away, or using currency or items that the player is not in possession of.
For turn-based games, such as chess or backgammon, it is possible to perform post-hoc validation of the game at its conclusion. This can be done even if the "AI" player's moves are computed on the client. The game client handles all of the game logic, but must record all of the player's moves and the ending state. If the AI's behaviour must appear to be random in some way, the server is responsible for sending a random seed to the client at the start of the game, which seeds a deterministic pseudorandom number generator. When the game is finished, the client sends the list of player moves and ending game state back to the server. The server then re-plays the entire game through and checks that each player move was valid and that the server arrives at the same ending state as the client provided. Since the same PRNG seed is used on both the client and server, the AI will make the same moves in both play-throughs. If the ending state fulfils the win condition for the game, and the moves/state were all correct, then the win is accepted.
More generic advice:

Ensure that a completion notification is tied to a new game notification, and that the time between those requests is neither too short or too long. New game notifications should contain all the relevant parameters for that game (game type, difficulty level, etc.) and server-authoritiative parameters (e.g. the AI seed) should be tracked.
Require that games with stages include stage completion notifications. Implement time restrictions on these.
Where possible, make random decisions on the server rather than on the client. For example, if a player gets a random prize, decide that prize on the server rather than the client.
Where you have deterministic games, get the client to record the sequence of moves and send them to the server. Hash the results and store this alongside the user profile. If the user then makes the exact same set of moves again over and over, the hashes will match up and you can identify that they are automating the game.
Analyse your player behaviours, based on logs, and come up with a reasonable upper bound for the rate at which games are completed and scores are increased. Set up alerts when users exceed this bound. If you ban cheaters quickly, they're less likely to come back and less likely to form communities that make your life difficult.


Where should I store a username during a password reset?

This is what I usually do:

The user asks for a password reset.

The system asks for the registered email.

The user enters email, and no matter if email exists or not, you say that you sent a reset link.

The server stores email, expiration and reset token on a reset_password table

When the link is accessed, expiration is checked and a form to reset the password is shown.

User only receives a link with a large random token.


What happens to messages sent in IRC without voice?

There are a few different aspects to this question:

Did the message reach the server?  Yes.
Can the IRC channel operators see it?  No.
Would it be possible for an administrator on the IRC server to see it?  Normally such things are not logged but it's their server so they could do whatever they want with the information that goes through it.
Could it get intercepted elsewhere in the process?  It depends if you used a secure (SSL) connection or not.  If you didn't, such a text message could be spied on its way to the server.


First, you need to fully understand Replay attacks.

A replay attack is an attack where an authentication session is replayed by an attacker to fool a computer into granting access. It may be any form or re-transmission of a network data transmission but is usually used to gain authentication.

So, it's not only a duplicate packet issue, and its danger is not about DoS attacks and other related problems.

And as for greater efficiency in exchange for less security, from OpenVPN website:

  Replay  protection is accomplished by tagging each outgoing datagram with an identifier that is guaranteed to be unique for the key being used.
  The peer that receives the datagram will check for the uniqueness of the identifier.  If the identifier was  already  received  in  a  previous
  datagram,  OpenVPN  will drop the packet.  Replay protection is important to defeat attacks such as a SYN flood attack, where the attacker lis
  tens in the wire, intercepts a TCP SYN packet (identifying it by the context in which it occurs in relation to other packets), then floods  the
  receiving peer with copies of this packet.

And that's explain the word greater efficiency, because the previous process takes its time.


What is the next step of this file upload attack?

One possible path would be to try and get it to be included somehow.  A lot of add-on frameworks can run an arbitrary PHP code file.  If the attacker was able to find such an add-on framework, they could give it the path to the file and it would be executed as PHP regardless of the file extension.


Question about a simple strong password management system

If you assume the attacker has the file, then you're actually relying on the number N as your password. You have stated that this is a user selected number, and it's likely that users would just chose (for example) 111....111, 123..., 000...000, or something similar.

This could be countered by telling the user what value of N to use at "generation time", however, it's likely that the user would write it down or similar. Humans don't remember long-distance phone numbers any more, heck, I don't remember any phone numbers anymore!

You've also stated that the number N maybe upto a billion or so, or roughly 10^9. This gives your password scheme quite a low entropy overall.


Consider a "zero-knowledge" file host such as mega.co.nz. How can one prevent users to upload unencrypted content?

It can't.

There are heuristics to tell whether a file is encrypted, but they're unreliable, and they're useless anyway.

An encrypted file is uncompressible because the encryption hides all the patterns. Except when it's not: if you encode an encrypted file in hexadecimal (with two bytes to encode each original byte), it takes twice as much room, so you can compress the hexadecimal version by 50%, but the hexadecimal version isn't less encrypted. Conversely, if a file is uncompressible, if may be encrypted, or it may simply be already compressed with an algorithm that's at least as good as what you have. So in fact an encrypted file may or may not be uncompressible, and a plaintext file may or may not be uncompressible,

An encrypted file contains no recognizable patterns. Except that of course it can contain, for example, a header indicating the type of encryption. Or it can recognizably contain only hexadecimal digits. So in fact an encrypted file may or may not contain recognizable patterns, and a plaintext file may or may not contain recognizable patterns.

An encrypted file may very well be a JPG picture of a giraffe, with information encoded in (say) the low-order bits of each pixel. See steganography.

Even if a file is encrypted, you can't tell, say, an AES-CBC-encrypted file from an AES-CBC-encrypted file with the key prepended. Except by trying to use the first 16 bytes as the key — and then you'd need to try out all the other ways the key may have been put in there.

Let's say that the file really is encrypted and cannot be deciphered with only the uploaded material. The creator of the encrypted file could still publish the key elsewhere.


Recent versions (presumably 1.0.2 and above) of OpenSSL supports -partial_chain option.
http://wiki.openssl.org/index.php/Manual:Verify%281%29

Regarding the use-case, it is for example usable in OCSP stapling (i.e. openssl ocsp command), in which case there is no merit in checking the status of the intermediate CA.


RSA: Do private keys have to be private? [...]  Does having a private key instead of a public key compromise the encryption?

Yes. For the reason Mike (I upvoted.) gave: The private key and the public key are not alike and the pubkey can be derived from the privkey. (And AFAIK this inequality is mainly for performance reasons and can also only be this way around and not the other way around.)

  so that all the clients can decrypt a message from the server, and the only the server can encrypt messages.

What you're describing amounts to a signature scheme. Everybody can be a recipient of messages but only a few participants can compose valid messages. This is functionally the same as as sending the message in the clear but attaching a signature to it. And signatures you can do with the privkey and verify with the pubkey.

Note: While they are related and it's sometimes explained as such: signing is NOT the same as encrypting with the private key. And verifying is not  the same as decrypting with the public key.


If you're always 30x redirecting from www.example.com to example.com, then yes, there's no reason this wouldn't work from a UX perspective.  There's certainly nothing stopping it from working from a technical perspective.

It is also certainly common to mix DV (cheap) SSL certs for secondary domains (like CDN domains for example) with an EV cert for the domain the page loads from.  The  browser's green bar is determined by the cert used for the session for the page, and that cert alone.  Beyond that, browsers only care whether or not all resources on the page are in fact loaded over HTTPS; they don't currently care whether or not the domains serving those resources present DV or EV certs, and there's no effect on the UX.


Secure and HttpOnly flag for load balancer cookie

HttpOnly - Flag tells user-agent(browse) to use cookie only in communication and do not allow access of cookie programmatically in JavaScript.
Secure - Flag tells user-agent to send cookie in communication only if communication medium is secure (HTTPS not HTTP)
If your cookie used in any HTTP communication then you may need to disable Secure flag but its not recommended.


In C, not using 'void' if a function does not accept any argument is a potential vulnerability

What happens here is that the foo() function uses a so-called old-style declaration, i.e. as things were done in C before the first normalization (aka "ANSI C" from 1989). In pre-ANSI C, a function bar() which takes two arguments of types int and char * would be defined that way:

void bar()
    int i;
    char *p;
{
    /* do some stuff */
}

and it would be declared the following way (usually in a header file):

void bar();

This means that code which uses the function would include the header file, which would then convey information about the existence of the function, and about its return type (here, void), but nothing whatsoever about the number of arguments and their types. Thus, upon usage, the caller must provide the parameters and hope that it sent the appropriate number and types. If the caller code does not do things properly, then the compiler will not emit warnings.

As a security vulnerability, it is not very convincing. It makes sense only in a context of code inspection. Some auditor is reviewing a lot of source code. An evil developer is trying to do evil things which the auditor will not notice (this is the scenario which is explored in the Underhanded C Contest). Presumably, the auditor will look at the header files and also at the start of the function implementation. In your example, he will see:

void foo()
{
    /* some stuff */
}

then the auditor may just assume that foo() takes no parameter, since the opening brace immediately follows the foo(). However, the caller code (which is elsewhere) calls foo() with some parameters. The C compiler cannot warn: since the function is declared "old-style", the C compiler does not know, when compiling the caller code, that foo() does not actually use any parameter (or so it seems). The caller code will push the arguments on the stack (and remove them upon return). The evil programmer then includes in the definition of foo() some handmade assembly to retrieve the arguments from the stack, even if, at the C syntax level, they don't exist.

Thus, a semi-hidden communication channel between two evil codes (the caller code and the called function), in a way which is not visible from a cursory inspection of the function declaration and start of definition, and, crucially, not warned upon by the C compiler either.

As a vulnerability, I find it pretty weak. The scenario is quite implausible.

The issue is more about quality assurance. Old-style declarations are dangerous, not because of evil programmers, but because of human programmers, who cannot think of everything and must be helped by compiler warnings. That's all the point of function prototypes, introduced in ANSI C, which include type information for the function parameters. In our examples, here are two prototypes:

void foo(void);
void bar(int, char *);

With these declarations, the C compiler will notice that the caller code is trying to send parameters to a function which does not use any, and will abort compilation or at least emit a sternly worded warning.

A typical problem with old-style prototypes is failure to do automatic type casts. For instance, with this function:

void qux()
    char *p;
    int i;
{
    /* some stuff */
}

and this call:

qux(0, 42);

The compiler, seeing the call, will believe that the two parameters are two int values. But the function really expects a pointer and then an int. If the architecture is such that a pointer takes the same size on the stack as an int (and also such that a NULL pointer is encoded the same way as an integer of value 0, which is a rather common feature), then things appear to work. Then compile that on an architecture where pointers are twice larger than integers: the code will fail because the 42 will be interpreted as part of the pointer value.

(The details depend on the architecture, but this would be typical of 16-bit C code compiled on a 16/32-bit architecture with 16-bit alignment, e.g. a 68000 CPU. On 64-bit modern architectures, int values tend to be 64-bit aligned on the stack, which saves the skin of many careless programmers. The problem is more general, though; similar issues occur with floating-point types.)

You should use prototypes; not because old-style functions induce vulnerabilities, but because they induce bugs.

Side note: in C++, prototypes are mandatory, so the void foo(); declaration actually means "no argument whatsoever", like what void foo(void); would mean in ANSI C.


Man in the middle using HTTPs downgrade to HTTP

I think you may have a slight misunderstanding in the premise of your question.  If the site does not use HSTS, and the user enters example.com in the address bar of their browser, the browser will default to http://example.com, not https://example.com.
See the following questions on security.stackexchange.com, and elsewhere on stackexchange.com, for more information on this behavior:
Why do browsers default to http: and not https: for typed in URLs?
Why is HTTPS not the default protocol?
https://superuser.com/questions/799464/how-does-a-web-browser-know-if-destination-is-http-or-https
This is precisely why we now have HSTS.  HTTPS Everywhere is another attempt at solving this problem.


What information can mouse recorders get?

If one  knows what is on the screen the movements and clicks tell a lot.

In order to protect against keyloggers some banking applications started to use on-screen keyboards to enter sensitive data like PIN or TAN. But then malware  started to track mouse movements and clicks to get back the information of what the user was doing. Banks tried to fight this with randomized layouts of the keyboards which only lead to not only tracking the mouse movements and clicks but also to do regular screenshots so that the clicks and movements could be interpreted.
See also the article Virtual Keyboard and the Fight Against Keyloggers.


Encrypting an object and storing the hash of its decryption key in the same database

Storing encryption keys next to encrypted data is always a security risk, even if the encryption keys are hashed.

Now if I understood correctly, the reason for storing the encryption keys is to check that the user can decrypt the data (since the key is hashed, you wouldn't be able to reverse the hash to decrypt the data). But for this purpose you can use an arbitrary piece of data that isn't the encryption key - just store that token and encrypt it with the same key.


I think you are missing -servername expired.badssl.com

$ echo "" | openssl s_client -connect expired.badssl.com:443 -CApath /etc/ssl/certs/ca-certificates.crt -servername expired.badssl.com 2>/dev/null | openssl x509 -noout -subject -dates

subject= /OU=Domain Control Validated/OU=PositiveSSL Wildcard/CN=*.badssl.com
notBefore=Apr  9 00:00:00 2015 GMT
notAfter=Apr 12 23:59:59 2015 GMT

Apparently this server hosts several HTTPS services...

$ host badssl.com
badssl.com has address 104.154.89.105

$ host expired.badssl.com
expired.badssl.com has address 104.154.89.105

... so the Server Name Indication extension is mandatory to get the appropriate certificate instead of the one corresponding to the default site.


While the SYN scan method itself is theoretically quicker, it doesn't mean that it will always be the best or fastest scan to use. It is possible that a firewall or IPS has detected the scan and is slowing you down (nearly every NIDS in the world knows about SYN  scans and will alert on sight).

You can also try adjusting the timing settings (-T[0-5], higher is faster/more aggressive).

In short, there is no one scan mode or setting that will always be fastest, and you should experiment to find what works best for the target.


Why not just accept all the passwords, you could, every time they set a new password, add it to a password list. All passwords in the list will be accepted rather than just one password. It might get spotted, but I believe the likelihood could be quite low OR it could be seen as a vulnerability.

You could then add some behavior to make it less obvious, for instance add logic  which says that if you have seen the IP before, then the password must be the password that the person last set from that particular IP. This will not cover people using proxies which change their IP constantly, but it should give you some coverage.


What are the security risks of letting the users upload content to my site?

There's a couple of risks from allowing content to be uploaded onto your site, but how important they are to you will likely depend on exactly how the site you're designing will work.

First up is malware upload.  If an attacker can upload malware onto your site and that malware is downloaded and executed by your users then that's likely to be a problem.  Preventing this usually relies on a combination of restricting the types of file that can be uploaded (one point to note is that you shouldn't just rely on file extension here), and using malware scanning on uploaded content. Of course the scanning side of things will only stop known signatures, and can be bypassed fairly easily.

Second potential problem is if they can upload active content and have that executed by your application.  So for example if your site uses php, then if they can upload a php script and then get it to run as part of your application then they are likely to be able to take control of the server, or at least access other information that exists in the app.

One approach I've seen to addressing this is to ensure that the uploaded files are not placed in the web root and ensuring that the web server will not execute files from that location.

A third risk, is users uploaded "illegal" material. This can be a tricky legal question to sort, but if you allow user generated content you're likely to have to deal with it sooner or later.  The fix for this seems to be primarily procedural.  Have a good relationship with your hosting company and ISP and ensure that you can respond to requests to have content removed quickly, if you're hosting in a jurisdiction that requires content to be taken down if a request comes in (eg, a DMCA request).


The TPM support is very rudimentary at this time. You'll need a bootloader that can extend the chain of trust and I only know of TrustedGRUB which is a pretty old version of GRUB with TPM-related functionalities added.

On the other hand, I believe the TPM is just all hype related to Bitlocker, practically it provides very little security (maybe that's by design to please the three-letter agencies?) as the machine now has all it needs to boot and decrypt its content without any other secret, allowing an attacker who stole the machine (even off) to boot it and then attack it with DMA or cold-boot attacks to retrieve the keys. TPM doesn't protect against that. Also, a theoretical attack I always think about is to simply sniff the low-speed serial bus the TPM is attached to and wait for it to transmit the encryption key. Only requires some wires to solder on the board, very easy and doesn't require expensive equipment.

An USB flash drive + keyfile/password would be way safer as the material needed to unlock the machine is now separate from it, if the computer is stolen off it's essentially an useless brick, there is absolutely nothing on the machine that holds the key.

Now, to answer your specific questions.

1) No, some unencrypted code has to be run before an encrypted partition can be decrypted and mounted, so the /boot, no matter where it is, should be unencrypted. The firmware (BIOS/UEFI) itself has no support for encrypted filesystems. Also, in case of disk encryption we're using symmetric crypto, so there is no notion of public key and all the TPM does is check if the data supplied to it (hashes of every component executed thus far and their configurations, so the firmware, its configuration, the bootloader, etc) and gives back a data block if the hashes match when the TPM was "sealed". This data block is the decryption key.

2) First, GRUB doesn't do encryption. The Linux kernel handles the crypto, which means everything before the kernel should be unencrypted. Finally there is no way to require both a password and keyfile with LUKS, but you can encrypt your keyfile with some program (GPG?) which you bundle into the (unencrypted) initrd and call it before passing the (decrypted) keyfile to LUKS to continue booting.

3) Sure. LUKS allows to transparently encrypt a block device by exposing its unencrypted version as a separate device node, so the system uses that instead of the real block device which now contains encrypted data. Whether it's an internal device, external, or some voodoo magic like an disk image file from an NFS server mounted as a loop device with LUKS on top, it'll work just as well (performance not guaranteed for the last one though). Whether you use keyfiles or passwords doesn't change anything either.


Is there a list of old browsers that only support TLS 1.0?

I am having trouble finding a list [of old browsers that only support TLS 1.0]

Lists of browsers with specific features

Trouble finding a suitable list might be partly because such a list might be large, incomplete, frequently changing and might need to take account very large numbers of plugins and addons.

As Tripehound mentioned in a comment. A browser might not be on such a list because it has support for TLS 1.2 even if support for 1.1 and 1.2 is disabled by default. This makes relying on a list more risky.

Depending on what you are doing, you may not need a list of browsers (user agents?).

Predicting Impact of barring browsers that use TLS 1.0

If you need to work out how many of a server's customers rely on TLS 1.0 you can enable TLS version logging in Apache and probably in other webservers etc. After a suitable period (e.g. a week) you would have some good statistics about the number of customers affected.

Preventing use of insecure protocols by browsers

It is often possible to configure web-servers and other services to not support TLS 1.0 - thus blocking browsers that don't support more recent versions.


I think your conclusion that brute force, SQL injection, and DDoS are the most common types of attacks doesn't include some of the other significant attacks.  XSS and CSRF are also notable, (see the OWASP top 10) and without doing detailed research into each type, it would be hard to know which is most prevalent.

General system hardening makes sense first:

Only allow public-key based SSH into the system.
Limit the inbound connections (as you've done with firewall rules)
Ensure each service runs as an isolated user.
Limit Unix permissions to the minimum necessary (0700 on directories, 0600 on files).
Where possible, remove write permissions to folders (limits possibilities for uploading malicious code)

Note that, since you're using nginx instead of Apache, some of the directives from the .htaccess file supplied by Wordpress should be enacted as equivalent nginx directives: e.g., preventing PHP execution anywhere user files are uploaded, limiting access to sensitive files.

For Wordpress specifically, I would review the Wordpress Hardening Guide.  Some specifics come to mind:

Use as few plugins as possible, and (if possible) review them for vulnerabilities.
Ensure that custom theming does not introduce XSS vulnerabilities.
If it's very important, consider a 2FA plugin for Wordpress to minimize the risk from brute force or password reuse.

If you're concerned about application-level DoS attacks, you can rate limit in Nginx.

Without more infrastructure (Cloudflare, Loud Balancers, etc.), you'll be unable to mitigate pure volumetric DDoS -- it's just a fact of the internet that if your attacker has more bandwidth than you do, you will lose.  These include attacks like reflected DNS/NTP DDoS, IoT botnets, etc.  Basically, any attack that allows the attacker to send more traffic than the internet connection of your host (all the way to the virtual interface on your VPS) can handle.  While Digital Ocean and other hosts have considerable bandwidth, your single VPS will quickly be saturated around (or before) 1 Gbps.


How secure is it to bundle unencrypted private key and a CSR into PKCS12 certificate?

Well, in the final PKCS12 you should encrypt the private key. The pkcs12 utility allows you to specify how you want to encrypt the private key.

-aes128, -aes192, -aes256
use AES to encrypt private keys before outputting.

-camellia128, -camellia192, -camellia256
use Camellia to encrypt private keys before outputting.

I would consider aes256 very secure for a private key.


Yes it could be hacked especially if password was not strong enough or simply because of vulnerable router.

Make sure that firmware is up-to-date, then check logs if it has one and change password to something decent.

Here it is how to reset a password:

Resetting the Linksys router to factory defaults

  If you can't access the router's web-based setup page or forgot the
  router's password, you may reset the router to its default factory
  settings.  To do this, press and hold the Reset button for 10 seconds.

  NOTE:  Resetting your router to its default factory settings will also
  reset your router's password.  The router's default password is
  “admin” as for the username, just leave the field blank.

  IMPORTANT:  Make sure that the Power LED of the router is blinking
  when you press the Reset button.  This indicates that the router is
  being reset properly.

  NOTE:  The location of the Reset button may vary for every model.
  Older Linksys devices may require pressing and holding the Reset
  button for 30 seconds to complete the reset process.

Source


What are the security implications of phone based keyless entry systems?

The biggest issue I find there is that your insurance company will not like Lockitron at all. So expect a price rise; or, quite plausibly, if your house is broken into and there is a Lockitron in place, then it will be used as an excuse to not cover your losses. Even if the burglar used the very old-fashioned entry method known as big-stone-through-window.

For availability, you should not rely on a Lockitron to allow entry, because:

Your Internet access might be down for some reason (including power outage).
Your phone might be inoperative (crashed, stolen, or even an empty battery...).
The Lockitron itself could be out of batteries (it is supposed to warn you in advance, but how reliable is this ? There is little available data).
The Lockitron company might go bankrupt at some point (not that I wish them so, but it happens).
The Lockitron servers could have some downtime.

So you should still have a physical, old style metal key in your pocket, if you want reasonable guarantees that you will be able to enter your home every night. Especially stormy nights, the kind of time when power or network outages are rather common, and you really do not want to spend the night without a roof over your head. The added value of Lockitron is not there (especially since a key is quite small compared to a smartphone); the potentially interesting part is in making it possible to remotely unlock the door. This is not a scenario which happens every day... which is a problem: if the device is not that useful, how will the company maintain financial buoyancy ?

Of course, Lockitron inherently obtains the power to open all locks. They promise that:

they are not evil;
they will not be hacked.

Both promises are somewhat empty, when you come down to it. Claiming "I am not evil" is what most evil people do; merely stating it does not inherently make it true (if you believe otherwise, and you are a US citizen, then rejoice! You will soon have an electorate choice between two non-evil candidates). For the non-hacking, well, it all depends on how competent the Lockitron people are, and also on a fair amount of luck.

And then there is the whole customization part. Lockitron says that the device can be extended in a whole lot of ways, with a rich API. When I read that, I think "exploitable security holes". The more complex a system is, the more probable security holes are. The device already does WiFi and Bluetooth, so it must contain a substantial amount of software. It might be not as hackable as your phone, but still...

On the positive side, Lockitron-like systems would be convenient for emergency services like firemen and medics (well, at least medics: a fireman's ax is remarkably effective at gaining entry almost everywhere). Assuming that they obtain a generic entry authorization, of course (which would itself be a security risk).


"Hello World" example of a Buffer Overflow attack in many programming languages

No such things exists on a modern system. 10 years ago I would have said one of the samples used in Smashing the Stack for fun and profit (probably example2.c).  But today buffer overflows are very complex and no two exploits are the same.  Buffer overflows are no longer the tool of choice for criminals.


TLS: how and when is the client's certificate used?

The reason you want to use a client certificate is for additional authentication.
The handshake works a bit like this:

The client sends the ClientHello.
The server replies with the ServerHello, which includes that the server wants to see a certificate from the client. Optionally, the server also includes details on which certificate authority the client certificate should be signed by. This is useful for clients automatically selecting the correct certificate out of many, but clients are free to ignore this.

What happens now depends on how the server is configured. There are several possibilities:
1. The server expects a certificate signed by a specific Certificate Authority.
The server has the certificate of a certificate authority (usually an internal one) and the server checks whether or not the certificate sent by the client was signed by this certificate authority.
This means that any client who does not possess a certificate signed by this specific (internal) Certificate Authority cannot make a connection to the server.
2. The server offers an optional client certificate.
This means that the client can send a client certificate, but the connection is not aborted if no client certificate is sent. Usually, in such cases, the certificate data (or lack thereof) is passed onto the application layer for processing.
For example, access to example.com does not require a client certificate, but access to example.com/admin/ does require a client certificate. Parsing of the URL path can however not be done purely through TLS and requires a HTTP server. So all the TLS library can offer is an optional certificate and the HTTP server needs to determine if it's valid and if the path requires it.
3. The client sends the wrong client certificate
For example, the server may require a client certificate signed by Example Corp. Root CA, but the client sends a client certificate signed by Attacker Corp. Internal CA. The server doesn't care about that, and rejects the certificate and ends the connection.

Also it should be noted that when I say a participant "sends a certificate", it's not just the certificate they send. There is also a validation that the participant possesses the associated private key.


What security protocols provide point-to-point confidentiality?

A VPN can connect machines or networks.  Depending on what's being connected, it may or may not provide end-to-end confidentiality.  There are three basic types of VPN: net-to-net, host-to-host, or host-to-net.

If your company has two offices, it might have a net-to-net VPN.  Each office has a VPN gateway, and when you connect to a server on the other end, your traffic crosses your office network unencrypted, is encrypted at the VPN gateway, is protected across the Internet, is decrypted at the remote-office gateway, and crosses the remote-office network unencrypted.  In this case there isn't end-to-end confidentiality; the traffic is unencrypted within the office networks.

On the other hand, two computers could both speak IPSEC, and could connect to each other in a host-to-host VPN.  This would protect traffic across the entire network path.  However, this is not a common configuration because lots of host-to-host VPN configurations require a lot of management.

The most common configuration is host-to-net.  For example, you might use a VPN client on your computer at home to connect to a VPN gateway at your company's network.  Traffic is encrypted leaving your host, but is decrypted by the VPN gateway and then crosses your office network unencrypted.


Why don't computers check whether there are memory contents in some memory space?

There is always something in memory. Each bit contains either a 0 or a 1 at all times. If the same space in memory is used for two different purposes, the computer (the compiler or the runtime system) can't tell: purposes are a human concept, not a machine concept.

On most systems that you'd think of as computers nowadays (PCs, servers, mobile phones, routers, etc., but not the pervasive kinds of microprocessors and microcontrollers found in most electronic components), there is a memory management unit (MMU). The MMU translates between memory addresses used by the program (virtual addresses) and memory addresses in the actual memory bank (physical addresses). At this translation layer, it's possible to mark some zones of virtual memory as inaccessible. If a program tries to use inaccessible memory, that program will be killed (Windows calls this a general protection fault, Unix calls this a segmentation fault).

It's possible to use the MMU for memory protection. In fact, that's how multitasking operating systems protect applications from accessing each other's memory. However, inside a program, the applications are limited. You can't put every variable of a program in its own zone surrounded by inaccessible zones. Well, you can, and some debugging programs do it, but that's very inefficient, because the granularity of the address translation is coarse (4kB on most processor architectures). And it doesn't solve all errors. If you have a 64-byte buffer followed by 4032 bytes of unused memory and followed by 4096 inaccessible bytes, an overflow into the 65th byte won't be detected (all you can ensure is that it won't corrupt other variables of the program); an overflow into the 4097th byte will overwrite something else. If you free an object and reuse its memory address for another object, but some part of the program still references the old object, that won't be detected either. (You can't keep addresses of old objects invalid forever, because you'll run out of addresses eventually.)

Many types of misuse of memory can be detected automatically, but runtime is not a good way to do it. You can catch errors sometimes — in addition to accesses to inaccessible memory, you can put explicit checks in your program or runtime environment. For example, you can attempt to detect a stack overflow by putting a known value at the bottom of the stack (a canary) and checking it from time to time. This does help against accidental errors, if the canary value is checked before damage can happen. When it comes to malicious attacks, canary values can make it more difficult to write an exploit, but they don't prevent everything. There are more complex methods of runtime checks, such as taking checksums of parts of memory and arranging to abort if those checksums don't match at a later; those are mostly used in hostile (“grey-box”) environments where the attacker has some limited means to perturbate the execution of the program.

The right time to detect misuse of memory is at compile time. There, it's possible to detect buffer overflows by ensuring that, for every instruction that accesses an element of an array:

either the compiler can prove that the index is always within the bounds of the array;
or there is a range check on the index immediately before the access to the array element.

Buffer overflows are only one of the problems. Another common problem is when a program frees the memory allocated to an object, but keeps a pointer to this object around and attempts to access the object later. There is a solution for this, but it has a strong implication on the language design. It implies that the language must forbid programmers from storing pointers in uncontrolled ways. There are several approaches:

the programming environment invalidates all pointers to an object when its memory is freed;
the compiler refuses to compile a program that frees an object when there are still pointers to this object around;
the compiler defers requests to free an object until it can prove to its satisfaction that there no pointers to this object remain.

Most programming languages solve these issues through some form of automatic memory management, where requests to free an object (if they exist at all) are not processed immediately, and all pointers are under the control of the compiler so that it can know what object this pointer is accessing. For example, the compiler sees that an instruction is accessing the 42nd byte of some object A, so it emits an instruction to check that A has at least that many bytes, and it records A as being in use up to that point so that A won't be freed earlier. The most common technique for automatic memory management is garbage collection: the runtime environment has a way to explore all the pointers of the program (which implies that the programmer can't make up a pointer in some hidden way), and it only ever frees objects when there is no pointer to them that the program can accesss.

A majority of programming languages out there use garbage collection and mandatory boundary checks (the two usually go together): C#, Java, JavaScript, Perl, PHP, Python, Ruby…. But the exceptions include some very common languages: C and C++. These languages are designed to give a lot of control to the programmer. They are not compatible with an approach where the programmer is forbidden from making up pointers.

Why do people program in such error-prone languages? Some of the reasons include:

The weight of history: programs are written in C, and they keep evolving in C.
Performance. Real or perceived. Automatic memory management has a runtime cost (but then, so does manual memory management).
The weight of history: programmers know C, so they write more programs in C.
Overconfidence. Many programmers believe that since they are smarter than a computer, the computer should not override their decisions. (I am smarter than the guard railing on my balcony; so why does it prevent me from walking off the 10th floor?)
The weight of history: there's a C compiler for every platform. Other languages tend to be less portable.

Languages where the programmer can't make up pointers turns programming errors
that would lead to arbitrary code execution due to a buffer overflow or access to a freed object into denials of service: the program may abort due to an uncaught out-of-bounds exception, or it may run out of memory, but at least it won't do the attacker's bidding. So they don't completely solve the problem — there's no miracle cure — they merely reduce its impact.

While languages with automatic memory management are a step up, they don't fully solve the original unsolvable issue, which is that memory is used for a different purpose from what it was intended for. They're only a step up, in fact. Instead of misusing bytes in memory (which is what buffer overflows can do), attackers may misuse strings: a string that should have been interpreted only as text intended for human beings, is instead interpreted as instructions in some programming language. For an example, an SQL injection attack consists of inserting a single quote in a string which results in part of that string being interpreted as SQL rather than, say, somebody's name. There are ways of relying on the compiler to detect such misuse, but most popular languages don't implement them, and most programmers have no idea that such techniques even exist (see Handing untrusted string input in print function and avoid buffer overflow for an idea of how it's done).


Storing encryption key in $_SESSION vs $_COOKIE?

The important thing is that key and encrypted data should not be stored at the same place, i.e. not both on disk, not both at the client side (no sending of encrypted data and storing the key in the cookie) etc. If the encrypted data remain on the server side both a cookie and a server side in-memory session object should  be safe enough. Cookies might be even safer than a server side in-memory session object because they are more temporary, i.e. the client will provide the key if needed and if not needed the key will not exist on the server at all, not even in memory.


Sending a reverse shell command through the drupalgeddon vulnerability isn't working

-I got it to work! For the future noobs like me there was 2 problems,
 +first make sure to urlencode the payloads you send ,or pass them into a variable and use
 the variable in the request.
 +secondly when trying to exploit this kind of vulnerabilities it is better to test on a
 ready to use test environments such built-in docker containers in order to avoid problems
 with OS and application firewalls and rules in addition to networking misconfigurations .
 -On the other hand if you're free and just playing with this at home feel free to test
 this on virtual machines to gain even more experience and perspective.


There was been at least five issues reported over the past few months

Problem with authentication, ie  if you could access a hard disc that contained a dropbox folder you would have continuous access to their dropbox data
Data stored in dropbox is accessible by dropbox employees
A recent code update meant that any dropbox account could be accessed with just the users email address for a short period of time.
The Terms of service were recently updated to give Dropbox much wider privileges to your data
You can detect if another user has uploaded a file to dropbox by monitoring the amount of time it takes to upload the file


Why should servers be placed outside of the corporate network?

Having all your corporate servers in the same network is a bad idea because if one of the servers is compromised, the attacker can easily spread out to the others. Servers are often configured to be secure on the front end, but when it comes to servers communicating with each other, there are various ways to find vulnerabilities. Also the sensitivity of data is often not the same. While a web server is important for the availability, a database server often contains valuable customer data. Separating these is a good idea in any case.

Specialized hosting providers for specific servers are mostly able to keep their servers more secure as well.

Thanks to the internet, there is no reason not to separate servers, unless your application is so time dependent that for example database servers need to be accessed directly.


Disable a specific services in Windows 7

If it's a computer (or group of computers) managed by Active Directory you can do this with Group Policy.

The settings is under Computer Configuration > Policies > Windows Settings > Security Settings > System Services.

If it's just on one computer you can just disable the service (Start > Run > Services.mmc) and change the Startup Type to Disabled.


Do I need a WAF in front of an API exposed by Google Cloud Endpoint

ESP is more for authorization and monitoring but does not provide the same functionality as a WAF. A WAF will protect you from attacks like SQL injection , well known Joomla ,  Wordpress , Apache vulnerabilities , etc.

It's seems like adding a WAF would be a good idea and improve your security posture.


Access rights management in large companies

Larger enterprises go through centralized initiatives led by the infrastructure team - the very same team that typically manages authentication. To make sure the access rights management works and scales correctly, many turn to standard architectures such as the one pue forward in XACML and older specifications.

This architecture defines the notion of:

policy enforcement points (PEP) responsible for protecting your app. These could be web access management gateways, API gateways, and more.
a central policy decision point (PDP) which processes authorization requests and produces an authorization decision
a central policy administration point (PAP) used to define and manage authorization policies.

To learn more I would recommend you turn to the NIST reports on RBAC and especially ABAC:

NIST RBAC
NIST ABAC

I also recently gave a presentation on externalized authorization management at the Cloud Identity Summit. You can download the slides here.

HTH,
David.


CTF competitions/challenges that are Windows based?

As a member of the active CTF team, which organized some competitions, I think I could say a few words how does it look from the inside.

First of all the licensing problem is in fact the main problem. But following your questions:

  Are there any CTF competitions that run that include Simulated Windows networks as part of the challenges (not just the usual RE binary challenges)?

I don't know exactly what do you mean by "Simulated Windows networks" but I guess you mean some kind of the vpn networks or other kind of virtualized networks in where you would need to find some vulnerable hosts and exploit them. The idea is good and I think the main limitation in here are the paid licenses of Windows products. In fact it quite hard to find any sponsor for the competitions (we often cooperate only with the organizers of the conferences where the CTF take place) and gain the money for this kind of request. Having in mind that we'd need to invest not only our time but also private money for the challenges, the choice between free Linux systems and their paid Windows counterparts is not very hard. What's more I've never heard about "two-days" Windows licenses and they would be the best solution in case of CTF games. The single license shared between different competitions is not the perfect solution too. Because of the aim of such competitions and nature of the players we need to consider the situation that our license key will be stolen. To prevent such a situation we would need to use some MAC, write the policy and hardend the system itself to don't let the players hack us too much. In my personal opinion it is much easier to do it on Linux than on the Windows systems. Summing up, because of reasons I've mentioned it's not profitable to setup such environments, even if it would be cool from contestant perspective to play on it.

  Are there any downloadable Windows VM's which come pre-configured (Say AD server and 2x client PC's joined to a domain for example but preferably with different configurations say for example kerberos)?

No, because of licensing reasons. I don't know if it could be ever possible. We could store the configuration itself that need to be applied or create the software that places the bug - but it's pointless in case of CTF competitions. It would be much easier to hack if you known where to look for a bug. What's more you'd require from user to have the exact copy of the system on his machine which is not preferable. The competitions should test mainly the skills - not the possessed resources (software & hardware).

  Aside from licensing issues, is there any technical reason why running Windows CTF's isn't practical? I can imagine running a Windows machine as a Virtual one is simple enough to snapshot and restore if someone playing is a jerk and decides to try and trash the machine.

Merging first and second answer... In case of online challenges - technically we'd need to assure the security of the host which for me looks harder than in case of open systems. For heavy-load challenges we would need multiple licences for all of the machines running behind load balancer. In case of offline challenges - we would require from user to posses exactly the same system or software which is not good - we would prioritize resources over the skills of the player.


In almost all cases I've seen (both working at a bank, and owning a bunch of credit cards), when the bank issued you your new card the old card was either immediately blocked, or set to expire (AKA be blocked) 30-90 days in the future. As a result, the magstripe and chip contained in the old card will soon be non-functional, assuming they are not already. I would recommend simply using the new card mailed to you by your bank, and not landing yourself on any watchlists by purchasing the expensive equipment required to attempt what you're looking to do.

Plus, depending on the bank, when you mess up and render the new card useless, they may take great pleasure in charging you a new card fee to allow you the privilege of continuing to access your accounts with them.


What career path do I need to follow to become a CISO?

From the CISOs I talk to, the only definite point is that they all come from very different backgrounds, but have a wide range of experiences...not just in the security industry (sometimes not even in the security industry)

Aim for a wide range of business experience, as at this level talking about security doesn't tend to have as much impact or value to a company as being able to talk about business risk, governance frameworks and value.

I wouldn't class any single discipline as 'more valuable' unless you count strategy, governance and business risk as disciplines. You'll want to be able to understand at a broad level what your teams across all disciplines are doing to help your organisation reach its preferred risk level at an acceptable cost.

This article from ComputerWorld UK titled "How to become a CISO" might also be of interest.

Also have a read through all the questions tagged professional-education - as there is a lot of useful information in there already.


Is a password-protected stolen laptop safe?

No.
The immutable laws of security say:

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

It doesn't matter if your laptop is password-protected or not. As long as the disk is not encrypted by a state-of-the-art encryption algorithm, anyone can access your data.

If I did not encrypt my entire hard-drive, does it matter how secure my password is?

No. Your data are safe if, and only if, the data are well encrypted. Password protection of an OS usually does not encrypt the disk (except on iOS, as far as i know). Consider using BitLocker (on Windows), FileVault (on macOS), or LUKS (on Linux).

Is it possible for someone to plug the hard-drive into another computer as an external drive and simply read all its contents?

Yes, someone will do exactly this.


How to verify CORS policy implementation?

Cors only works for ajax requests, not direct http requests. Before the GET request is issued in an ajax request, an OPTIONS request is issued to determine if it is from a valid domain. If it violates the CORS policy, the GET request is never issued. This doesn’t happen if you just issue a direct get request. A good way to test is to write some javascript that fires off an ajax request and deploy it to a server that is on a different domain. Visit that domain, and see if the call succeeds. With the header that you listed above, it won’t.


Ideally, we should do most (but not all !) of the hashing on the client side.

The overall need for password hashing, with all the involved iterations and salts (see this answer), is to make sure that the value which is stored (the "password verification token") cannot easily be used for an offline dictionary attack (the attacker tries potential password, until one which matches the stored value is found). For that specific functionality to be fulfilled, it suffices that the slow-and-salted password hashing occurs "somewhere", and the client machine is a reasonable place for that.

However, protection against offline dictionary attacks is only one part of the security goal. In particular, we do not want an attacker to be able to obtain "password-equivalent" values. If you do the complete hashing client-side, and store the value "as is" on the server, then a glimpse on the server's database (as happens all too often with SQL injections and lost backup tapes) will reveal the hash values and allow the attacker to log in as any user immediately. Thus, you still want to do some hashing server side.

What works, for instance, is to have the slow-and-salted hash on the client, resulting in a value V, and the server stores SHA-256(V). Since the slow-and-salted hash has been done, the protection against dictionary attacks is there; and since the server does not store V but still requires the client to send V to be granted access, read-only breaches are not trivially escalated into full read-write compromise.

Client-side hashing has the very interesting feature of using client-side resources, not server-side, thus allowing a given server to process many concurrent clients without running out of CPU, while still having an overall slow-and-salted password hashing. However, this is not often done in practice because of some drawbacks:

The client cannot hash without knowing the salt, which is stored on the server. The protocol thus implies an extra roundtrip: the client must send the username, the server responds with the salt, and then (only then) can the client do the slow-and-salted hash.
Clients are heterogeneous: some can be quite feeble, which implies a hard limit on the number of iterations that can be applied (because a slow smartphone as client does not mean that the human user is more patient). This is especially true for Web-based clients, because Javascript computations are awfully slow (when compared to native code or even Java or Silverlight applets).
Client-side hashing means client-side code, which may not be easily upgraded or modified. With server-side hashing, the hash function choice is entirely up to the server and can be switched without having to alter installed clients in any way.
Some servers like to have access to cleartext passwords occasionally, not for storage, but for other features such as automatically detecting very poor user passwords, or sending a copy of the passwords to the relevant Law enforcement authorities (where applicable -- I am not saying that this is good or bad, but when it applies, it is not subject to a choice by whoever designs the login system; if you are in a country where you must allow governmental agencies to peek at passwords, then, well, you must, so this becomes an element of the context to be dealt with).


Why do we need HTTPS for static content? If we can have a checksum at the end signed by the private key, won't that prove the validity?

I think you're setting up a strawman with that question. We don't in fact need HTTPS for static content, and the purpose of HTTPS isn't just to prove the validity of the content. That's just one of several purposes.
The move to switch a huge number of sites to HTTPS (even those serving harmless static content, such as wikipedia) in the last couple of years didn't primarily happen because people were worried about getting the wrong content; it's because people were worried about three-letter-agencies spying on users; e.g. the large-scale move to HTTPS happened primarily for privacy reasons (see for example RFC 7258, Pervasive Monitoring is an Attack.)
Your idea of using a signed checksum is already in production all over the internet: Software which you download is often verified like that. Package managers / update systems of most operating systems do this, and individual software projects do it on a smaller scale by publishing pgp / gpg signatures along with their software downloads.
This all works irrespective of whether these downloads are delivered via https or not, although https is often used in addition.
You're suggesting to add a third protocol besides http and https, maybe one called httpv for "verified", that builds content verification into the protocol but leaves out the rest of ssl.
I agree there would be an advantage to serving some static content in the clear so it can be cached. But this is not an option if you're worried about privacy issues in light of the intelligence community's programs to spy on all our communication.

Any particular reason why this semi HTTPs not considered?

So I'd assume that your third protocol can't gather much steam because

there already are solutions which work in place when we really need to verify content, and

with so much of the internet now becoming encrypted to guard our privacy, it seems like there wouldn't be much use for another protocol that didn't protect against spying.