How can I exploit a PHP endpoint that lets me instantiate an arbitrary class?

I don't think that you can do anything with just this code.

But that does not mean that this is secure in any way. You give up the control flow of your application to the user, which is not a good idea.

For example, if you were to call close on the newly created object, an attacker would gain SSRF:

$obj = new $_GET['x']($_GET['y']);
$obj->close();

// SSRF:
http://localhost/shell.php?x=SoapClient&y=http://localhost/called

Or if you had a class such as this, an attacker would gain session fixation:

class Session {
   function __construct($sessionId) {
       session_id($sessionId);
   }
}

// session fixation:
http://localhost/shell.php?x=Session&y=123

Or you may have a class like this:

class File {
    function __construct($filename, $content) {
        $this->filename = $filename;
        $this->content = $content;
    }

    // [...]

    function save() {
        file_put_contents($this->filename, $this->content);
    }
}

And lets say the classes that users are supposed to create also have a save method (eg to save the object to the database). Now an attacker would have code execution.

It's easy to imagine a lot more scenarios like this, where either a constructor of a class does something dangerous, or a dangerous method of a class has the same name as a safe method of the class you expect.

It's likely that your current code base would allow an attacker to do at least something.

Depending on your code being secret is also not a good idea. Your code should be secure, even if the source code somehow leaked.


Does facebook/google app id need to keep secret if possible?

Not a risk. The app ID is intended to be public; this is how you're supposed to use it.

The app secret is -- as the name implies -- the part which has to be kept private.


Certicate verification with OpenSSL commandline

The first error was due to your trying to 'read' (and verify) a non-existent file.

The second would seem to not be an error, but a 'proper' failure to verify.

What the message actually says it that it cannot find the CA that issued the cert you are testing, and so cannot validate the chain (which would generally be, at minimum issuing CA > your cert).

The SSLeay demo server line in your second output would tend to indicate one reason for this is that indeed, you just generated a new CA.

It also looks like you are trying to validate your own CA cert, which is a little redundant - but if you really want to do that, you should run:

openssl verify -CAfile cacert.pem cacert.pem

A more useful/practical example would be validating a (hopefully) known-good cert. Not sure if you can pipe on Windows, but on Linux, you could do:

openssl s_client -connect google.com:443 </dev/null | openssl verify

If you want to see the cert, you can run:

openssl s_client -connect google.com:443 </dev/null | openssl x509 -text

I think you might want to spend a bit of time reading up on how PKI works: generally, a PKI is built when a 'trusted' entity (a Certificate Authority) issues a certificate for another entity - it basically vouches for that other entity (which can be an organisation, a server, a user, etc) being who it claims to be.

So validating/verifying a cert involves the following (grossly simplified explanation coming up):

from your end-user cert (i.e. the cert used on the domain you are checking - user here is whatever is making use of the cert, not necessarily a human), the Issuer is checked, and the Issuer's public key is also extract (for comparison against known keys for that issuer).
you could then check first that your end-user cert is properly signed (i.e. the signature contained in the cert is signed by the private key linked to the Issuer's public key, which is included in the cert)
you could then validate the Issuer's cert, either by checking a list of known-good certs (which is what the OS cert store does), or by repeating the previous two steps if the Issuer has been issued its cert by some other entity.

At some point, you end up at a self-signed cert belonging to an entity such as Verisign/LetsEncrypt/YourCAHere, which is the root of the chain of trust the PKI reflects.


Is the execution time for bcrypt independent of the length of the input string?

Execution time in bcrypt does not depend on the input size; internally, the input string is padded into a fixed-length sequence of bytes, and that sequence is then used throughout the algorithm.

It would be a problem if execution time depended on input size, because the "cost factor" parameter is adjusted to make the execution time as high as is tolerable. The question is relevant, but, fortunately, bcrypt does not have this specific weakness.

Note: input passwords for bcrypt have a maximum size of a few dozen bytes. There are ways around it which involves a pre-hashing step (that step would take a time proportional to the password size, but it would be muuuuuch faster so the time overhead would be negligible, unless you are in the habit of typing passwords of several megabytes, which is impressive but weird).


What is the benefit of public Certificate Authority when using SSL mutual authentication?

In terms of SSL Mutual Authentication a self signed CA and a public CA provide the same functionality, is that assumption correct?

Yes.

  Meaning the client will be able to communicate with the server only if both of them have the certificates issued by the same CA and the server has access to the CA, right?

No. The role of the CA is to attest that an entity holding a certificate is entitled to have it. It makes sure that nobody can get a certificate for Google, except Google. That's why a CA exists.

The CA certificate is usually shipped with your OS and your browser. After receiving any certificate, the TLS libraries will check (unless told no to check) if the certificate was issued by a trusted CA, if it's expired or revoked, and here ends the CA involvement.

Mutual authentication does not depend on a CA at all. Does not matter if a certificate is self-signed, issued by a private CA or a public one. It only depends on the certificates. If I create a certificate myself on my computer, ship it to you and you configure your server to talk to me, it's done.

  So in this situation, the man-in-the-middle attack is only possible of the attacker has access to the self-signed CA, correct?

No, a MitM attack can only be conducted if someone steals the private key of both the certificates (client AND server). If they steal the client's certificate, they can impersonate the client to the server, but not the other way around.


A potential solution could be to rely on intermediary servers and don't allow P2P communication for untrusted clients.

Let's say it's a chat program (like Skype), the client at the same time becomes an intermediary server on the network and is able to relay data between other clients.

For someone to contact you, he first must look up the IP of the intermediary node(s) you are connected to (through a DHT or something similar) and then send everything they want to say to you to that node, which will relay it to you. No possibility of DoS here as bringing down the node won't do any good and your client will immediately reconnect to a different one.

Once that data reaches you (through the intermediary), let's say it was a contact/chat request and you accepted it. At this point, you trust that person to not do anything malicious and give them your IP (through the intermediary as always), and then he connects directly to you. Also, if it was a contact request, your client also saves their public key which means the next time the person goes online this entire process will be done automatically and your client will give them your IP right away (through an intermediary as always).

This can eventually be thwarted by flooding the network with malicious clients (which will act as intermediary nodes but won't respect the confidentiality of other node's IPs) but once the software gets popular and there are enough legitimate nodes it'll be very hard to do that (think about a sybil attack on Tor).


Why is PKCE secure against man-in-the-middle attacks?

Such a man-in-the-middle attack is prevented by the use of TLS.

RFC 6749, section 3.1 (OAuth 2.0 Authorization Framework) explicitly states that TLS MUST be used for the communication with the authorization endpoint. And even the introduction of RFC 7636 (PKCE) states the following when referring to the authorization request that returns the authorization code:

  Because OAuth requires the use of TLS, this communication is protected by TLS and cannot be intercepted.

The use of TLS (or IPsec) is further recommended for any OAuth communication by the security considerations described in RFC 6819, see section 5.1 (in particular the first two sub-sections).

The part that PKCE protects against is the possibly unprotected communication to the redirection endpoint. For native apps the custom URI scheme generally used might also be registered by a malicious app, allowing it to intercept the authorization code. But without code verifier it won't be able to request an access token.


Security attacks on PHP web applications

Yes, there's definitely a lot more.  I suggest that you start by reading about the OWASP Top 10.  Every web developer needs to be familiar with each of those categories of threats.

In addition, here are some good introductions to web security:

An excellent overview for developers -- this should be a must-read for every programmer doing web development.
Web security tutorials at Google Code University

P.S. Some other categories to make sure you know about: path traversal, session management, secure password storage, clickjacking, phishing, site-wide SSL.


The purpose of salting is, that one cannot build a rainbow table to get several passwords at once.

Without salting: An attacker could search the internet for precalculated rainbow-tables and find the passwords with no effort.

With a constant salt: The attacker has to build one rainbow-table for this specific salt, and can then get all the passwords with this single rainbow-table.

With a unique salt: If each password get its own salt, the attacker has to build a rainbow-table for each password. In this case brute-forcing is faster, it doesn't make sense to finish the rainbow-table after finding a match, because you cannot get other passwords anyway.

So you see, even if the salt is known it fulfills its purpose. If you want to add a secret to the process, you should instead use a server side key and encrypt the already calculated password hashes. Do not mix up salting with other security measures.


Probably Not Feasible

Background

In CHAP, the authenticator sends a challenge, and then the client responds by hashing the secret plus some other data from that challenge.

This is comparable to sending a new salt every time, and it does not represent the scenario hashcat was designed for.

That said, the response contains an MD5 hash of challenge ID + secret + challenge value. Two of those values are transmitted over the wire. The resulting MD5 hash is also transmitted, so you have everything you need to recover the secret in theory.

The problem is getting the existing tools to work in this scenario.

Methods

You could take three approaches.

You could generate a wordlist consisting of randomly-generated secret candidates and concatenate them with the ID + challenge using rules. (Extremely slow)
You could create custom character sets for each character in the ID + challenge and run a bruteforce mask attack. (Fairly slow)
You could attack similar to option 1, but with a regular wordlist; however, this will only succeed if the secret is in your dictionary. (Fairly fast)

Expectations

Typical CHAP secret lengths are 12-16 bytes/characters. You could probably run #2 for 8- or 9-character secrets in a reasonable time frame, but longer secrets would be problematic even with high end hardware. You are looking at years, even with dedicated multi-GPU rigs.

This leaves #3 as the only feasible option, which means your efforts are tied directly to the quality of your wordlist and the CHAP secret.


Every country treats it's citizens privacy differently. In general, some countries do have laws which allow collection of such data. In the United States national security letters (NSLs) have been sent to companies to request such data and in some cases more data than just the metadata. I'll also add that some of the metadata collection may also be handled at the ISP level such that a government could potentially request that the ISP's collect connection data but never approach the company directly. This is a very broad question and the answer is a bit different for every country and even within different branches of governments in those countries but some countries definitely have laws allowing them to request this type of data.

https://en.wikipedia.org/wiki/National_security_letter


Opt-in a security profile at runtime, without tedious setup

Not really what you want, but more closer variant is:

normal@user:$ aa-exec -p restricted_books booyah

In this scenrio you still need:

Enabling AppArmor
Writing a profile
Registering profile

But after that you can confine any application with any profile as normal user by aa-exec (confine a program with the specified AppArmor profile).
More detail in man aa-exec


How to protect against a user using many different IP addresses and creating many accounts?

There are different approaches, based on how badly you want to prevent users from creating new accounts. While this isn't a comprehensive list, it should give you an overview of what is being done:
Just let them
The simplest approach is to not care at all. If your users want to create multiple accounts, you just let them. While this may sound like "The safest way to ski is not to ski", it is indeed how some services operate. Not every user with multiple accounts has those for malicious reasons. For example, you could create a second Stack Exchange account for a question that you may find embarassing or for which you may have personal reasons as to why you don't want to have it connected to your other account.
Tie registration to a difficult-to-obtain factor
Phone numbers aren't as easy to obtain as they used to be. Back in the day you could buy 20 pre-paid sims with individual phone numbers at the grocery store and nobody would bat an eye. Okay, maybe the cashier would look weird at me, but she doesn't get paid enough to care.
These days, even prepaid SIM cards are more difficult to come by, so an attacker who wants to have lots of different accounts has to go through significant trouble to get them. If their costs to get a new account are higher than their expected gain, it'll not be worth it anymore for them.
Make them pay for a new account
You could tie accounts to licenses. As such, if a user wants to register 10 accounts, they need to buy 10 licenses. While obviously this strategy doesn't work for every kind of service, it does indeed work for some kinds.
Cheating in an online game, for example, becomes less desirable if you need to pay 40€ for a new copy of the game every time you are banned for cheating.
Analyze their behavior
This approach requires considerable investment, but you can build a system that looks out for anomalous behavior and flags it for manual review. For example, if two accounts constantly and almost exclusively upvote each other, then you can be pretty sure that those are sockpuppet accounts.
Of course, the actual implementation of such a system is difficult and will include lots of false positives and false negatives, but depending on how badly you want to stop people from using multiple accounts, it may be worth it.


How do RF remote clones manage to clone rolling codes?

Generating rolling code is as simple as passing a secret key (sk) and initialising it with an incremental value of counter.

HMAC-SHA256(sk, counter)

Most of the key fobs use proprietary algorithms to generate rolling codes. You can't create a universal remote even if you know which algorithm manufacturers are using. The seed value is unique per key fob. To generate same rolling code as the targeted key fob, you need to know this seed value or a secret key depends on the implementation.

The easier way is instead of figuring out the secret value, clone the rolling code and replay.

Jam+Listen(1), Jam+Listen(2), Replay (1)

2nd rolling code is still unused and can be replayed later. This is called rolljam attack. Hacking a Car’s Key Fob with a Rolljam Attack

This attack works on any key fob which doesn't authenticate the device. A generic remote exploiting this attack can be built using software defined radio. You don't even need to know the underlying implementation.

  The so-called "universal remote" manage to clone rolling-code remotes when fed the master key

It is still not universal. The master key is specific to the manufacturer and its car model. You can derive the secret key for key fob using this master key but you also need to implement the same algorithm specific to the manufacturer.


Is typing the PPP password in the PPP username a risk?

No.  There is no security difference between the username and password fields here.


Ask a lawyer for legal advice, but yes.  There are many VPNs and proxy services run in the US, and the most common use of VPNs are for corporate connections, so there are literally thousands in use at any time.


The various authentication methods of MySQL are publicly documented in the manual:

http://dev.mysql.com/doc/internals/en/authentication-method.html

What you describe might be a method called Secure Password Authentication.


Given a secure channel, are there any benefits in using SCRAM over a username and password?

tl;dr: I wouldn't generally recommend it, but it may be useful in specific circumstances

Advantages of SCRAM

The password is never sent to the server. The only things sent on the wire are:

The nonce
The salt
The iteration count
HMAC(PBKDF2(password), "Client Key") XOR HMAC(H(HMAC(PBKDF2(password), "Client Key")), AuthMessage) (seriously, I'm not making this up!)
HMAC(HMAC(PBKDF2(password), "Server Key"), AuthMessage)

The server never knows the password, and thus can't impersonate the user on other servers (as long as the salt on those servers is distinct from this server's salt)

Disadvantages of SCRAM

Requires the use of PBKDF2. While PBKDF2 is significantly better than a fast hash, bcrypt is better (and nowadays you should consider Argon2 as well).
Requires that all of the computational complexity be handled by the client

The first point is unfortunate, but the second point is the real killer. With smartphones and tablets everywhere now you simply can't assume that the client will be able to quickly compute PBKDF2 with enough iterations to be safe.

When would SCRAM be useful?

The use I see for SCRAM is where the client is trusted but the server is not. This is never true for a web application (as the "client" is the JavaScript sent by...the server), and is only sometimes true for local applications. The best examples I can think of are the ones Wikipedia gives: SMTP, IMAP, and XMPP, where you trust your email or chat client but are authenticating to a potentially malicious third party server.

If the client forces a high iteration count and unique salt it may mitigate the risk of DNS hijacking combined with a rogue CA, but you've already done that with certificate pinning. The only thing left to defend against is your server being malicious, which may be useful in some cases, but only if the gains outweigh the disadvantages of SCRAM.

SCRAM could useful to keep the server from obtaining the password if you know that a strong password will be used, but that the password will also be re-used elsewhere (if it's not reused why would you care if the server might know it?). Unfortunately this can't really be enforced, and the ideal would be to use a unique password anyway.

How does SCRAM work?

In SCRAM, the server stores:

The salt
The iteration count
ServerKey = HMAC(PBKDF2(password), "Server Key") (where "Server Key" is a known constant HMAC key)*
StoredKey = H(HMAC(PBKDF2(password), "Client Key")) (ditto for "Client Key")

To authenticate:

The client sends the username and a random nonce
The server appends its own random nonce to the client's, and replies with the nonce, salt, and iteration count for the user
The client computes the following:

ClientKey = HMAC(PBKDF2(password), "Client Key")
StoredKey = H(ClientKey)
ClientSignature = HMAC(StoredKey, AuthMessage) (where AuthMessage is the concatenation of all previously exchanged messages and the nonce, delimited by commas)
ClientProof = ClientKey XOR ClientSignature

The client sends the nonce and ClientProof to the server
The server computes the following:

ClientSignature = HMAC(StoredKey, AuthMessage)
ClientKey = ClientProof XOR ClientSignature
ServerSignature = HMAC(ServerKey, AuthMessage)

The server verifies H(ClientKey) == StoredKey, proving that the client knows the password (or at least ClientKey)
The server replies with ServerSignature
The client computes ServerSignature and compares it to the value returned by the server, verifying that the server knows the ServerKey

This is rather simplified, as it excludes some things like hash selection, encoding, message format, and channel binding, but it should give a good idea of how it works.

* All uses of PBKDF2 obviously include the salt and iteration count as well, SCRAM sets dkLen to the output length of the selected hash


How do defend CSRF against requests that pretend not to be browsers?

You shouldn't need to block non browser requests.

The reason? Csrf is an attack on a user using a browser. They need to be visiting your site at the same time as a malicious site.

If there is no browser, there is no attack. So just let the non browsers through.

Update: After Anders' comment I now realise the question was relating to websites that already allow through state changing requests based upon User Agent. Please see his answer as it sums up the situation nicely in respect of this.

My new answer:

The best approach isn't to use a browser based authentication mechanism for sensitive functions. For anything accessed outside of a browser, enforce access using API keys sent as headers within the request. Automated systems using APIs shouldn't be using a username & password and gaining a session token, they should have a strong key that could be attached with every request.

This way it does not matter what the User Agent is - you identify non-browsers by the fact they are using an API key sent in a header to authenticate themselves.


Those are very general questions, so I can only give a general answer. Security can be evaluated in the context of a concrete threat model.

  Does anyone know if there was any study done on the security of GAE in comparison to other servers for web apps?

http://scholar.google.com is a good source of scientific papers.

  What would you say are the most likely weak chains in creating a web app on GAE an handling users' valuable information?

The typical weak link of self written web applications are query injection, Cross Site Scripting and Cross Site Request Forgery.

Google does support a secure authentication service which can be used by app engine programs, which prevents many common mistakes.

  For example, is the web app only as secure as the web admin's password

Yes, like a chain, the weakest link defines the overall security.

  Or can there be some other security measures in place to prevent even the admins from accessing users' information stored with the app?

Since client side encryption is not feasible for web applications that are targeted at ordinary users, there is no way to protect against malicious manipulations of the web application done by the admin.

Furthermore it means that any information you store is accessible by Google, since they have both access to the data store and the application code (which might have hidden encryption keys).

Especially the last point is a huge issue, if European privacy laws apply to you. Google was forced to admit that they handover information stored in Europe about European citizens if asked by the US. The problem is that this illegal activity (see green box) by Google might cause legal trouble for the person or company using Google Services to host customer data. It is the responsibility of the company collecting data to ensure that contracted service providers comply with European law. (I am not a lawyer, so this paragraph is only as far as I understand it).


Who can spy on my wifi usage and websites I visit?

Contrary to a common misconception, the network key is not the encryption key.  The WiFi communication is encrypted on its own using a key exchange protocol.

This makes it impossible for anyone without abnormally huge processing power to decrypt anything that goes through.

That said, if the person controls the router, that changes things as the router can see everything that goes to the Internet which is not encrypted.

The router can see..

everything you send and receive that is not encrypted including documents, pictures, URLs, emails
most hosts that you visit even if using HTTPS because of its DNS server which allows the hacker to match the IPs with the hostname even if the HTTPS protocol can hide it
the type of things you do based on certain factors like the port number, bandwidth used in both directions, and session duration

Some would tell you that you might want to use a VPN to hide most stuff from the wifi router's owner, but you would then put it in the hands of a total stranger which is not better.

Real solutions include (and may combine):

Using secured connections for everything you prefer to keep private.
Getting your own Internet connection, therefore being free from the undesirable watchdog.

So, based on all that, Wifi peers are of very limited risk of knowing more than the bandwidth patterns which may be spied on.  The only people who really have access to spy on what you do are upwards in the network, starting with the Wifi router's owner which could see everything that I mentioned can be visible.

Any other equipment on the network path followed by each of your connection can see the same kind of things in their context which is typically limited to one (or very few) connections you do.  The closer they are to you, the more they can see, which means that your ISP would see almost everything that your Wifi router's owner would.


Transfer requests for localhost zone on my bind DNS server

This is your guy: https://www.alphastrike.io/

In their own words:

  Alpha Strike Labs are a security consulting company specialized in
  industrial security and advanced security assessments. Based in Berlin
  and Vienna, we pride ourselves on offering high-end professional
  services in various areas of Cyber Security.

  Do I need to be concerned?

In short, no. But nowadays most DNS servers are configured to deny zone transfers, because that makes reconnaissance of your infrastructure a bit too easy. On the other hand, this is not secret information. A good chunk of your zone can be reconstructed from indirect methods like scanning your IP range and doing reverse DNS.

  Why do they transfer the localhost zone?

Generally speaking:

An entity that can enumerate your zone can figure out all the hosts you have declared, and there are legitimate reasons for this: research. A number of outfits such as Internet security companies probe the Internet for research and statistical purposes. A very common example is measuring the market share of Internet software vendors like web or mail servers.
That could have been a search engine too. They have to use every trick to discover, craw and index new hosts that would otherwise go unnoticed.
Bottom line: any machine that is exposed on the Internet is going to be probed all the time, and not all probes are malicious.

But the interesting question here is: why do they transfer the localhost zone specifically ? Normally the zone looks like this:

localhost.      604800  IN  SOA localhost. root.localhost. 2 604800 86400 2419200 604800
localhost.      604800  IN  NS  localhost.
localhost.      604800  IN  A   127.0.0.1
localhost.      604800  IN  AAAA    ::1
localhost.      604800  IN  SOA localhost. root.localhost. 2 604800 86400 2419200 604800

So I am not sure what kind of juicy details (internal hostname ?) they are expecting to find here. You could contact them directly and ask. A legitimate company should not be ashamed to explain why and how they are probing your systems.

  Why is this transfer successful? (*)

AFAIK this is allowed by default in Bind. You can deny AXFR on a per-zone basis or globally. To disable it globally you could add this entry: allow-transfer {"none";}; in named.conf. If you have slave name servers that sync with a master using AXFR, then whitelist their IP addresses or range. Otherwise zone transfer can be safely disabled  as there is no reason to expose your zone to the whole world.

See allow-transfer


Your exploit needs page.h header file.
 You must install linux header package.

asm/page.h is available in linux header package

  linux-headers 3.11.6-1 File List :
  .
  .
  .
  usr/src/linux-3.11.6-1-ARCH/arch/x86/include/asm/numaq.h
  usr/src/linux-3.11.6-1-ARCH/arch/x86/include/asm/olpc.h
  usr/src/linux-3.11.6-1-ARCH/arch/x86/include/asm/olpc_ofw.h
  usr/src/linux-3.11.6-1-ARCH/arch/x86/include/asm/page.h
  usr/src/linux-3.11.6-1-ARCH/arch/x86/include/asm/page_32.h
  usr/src/linux-3.11.6-1-ARCH/arch/x86/include/asm/page_32_types.h
  usr/src/linux-3.11.6-1-ARCH/arch/x86/include/asm/page_64.h
  usr/src/linux-3.11.6-1-ARCH/arch/x86/include/asm/page_64_types.h .
  .
  .


Can an attacker see Cookie Contents via CSRF attack?

When the targeted application does not properly validate the origin of the request a Cross Site Request Forgery attack is possible.

It is an attack which forces end users to execute undesired actions on a web application in which they are currently authenticated.

Due to the nature of web browsers, all cookies are transmitted in the malicious request to target the web application.

  Can the attacker see cookie contents like Session ID or some Data stored Inside Cookie?

No, this is not possible in a Cross Site Request Forgery attack. However, if a Cross Site Scripting attack is also possible this may be possible depending on the cookie's attributes (e.g. HTTPOnly)


How much is known about who is responsible for all the database breaches?

Whilst it is going to be debatable about whether these sources are reliable, there are a fair number of sources of information about data breaches, which generally touch on who they think is responsible.

Verizon DBIR
Secureworks Cybersecurity Threat insight Report
EY Global Infomation Security Survey

Basically there's loads of these reports from companies who deal in this space, which can be read to try and derive a picture of who's responsible for what.


A low tech yet secure way to keep track of passwords?

If her sole objection to LastPass is that the passwords are "out there", then I recommend using KeePass instead. It works similar to LastPass, but keeps the password database locally instead.

If she needs the passwords to be handy on-the-go, you can use KeePass as a portable app on a USB drive.

If you're really paranoid as to what might happen if the storage media containing the passwords is compromised, (even though the KeePass database is already encrypted) you can store the KeePass database within another encrypted container (TrueCrypt was previously recommended, but now defunct). Some encryption solutions have portable versions of the tools needed for using their containers on the go.


Schneier is telling me to write my bank security password and keep it in my wallet? Is that right?

I think it is bad advice. I want to break the answer down in two sections, namely using the same password on multiple sites as well as your original question about storing a password on a piece of paper in your wallet.

Thoughts about storing passwords on paper (and in your wallet)
As of today there are multiple good password managers which are better then the alternatives out there, such as writing a password down on paper. Troy Hunt actually made a really good blog post about this subject. In general it is considered a bad security practice to write down passwords, because of several risks involved:

You can lose the paper with your password on it, this would mean you lose access to that password but also someone else might be able to use it depending on where you lose it;
Someone might be able to use the password when he steals the piece of paper or when he can take a look at it, similar to shoulder surfing.

When you take into consideration people (including you as I can tell by your question) losing their wallet with both the password and banking details from a credit card or banking card, I would consider this a critical risk to your finance and personal data in general. A wallet is not made to secure money, it is meant as storage. The same principles should be applied to using it to secure your password.

Thoughts about using the same password on multiple sites
It is also not considered a good security practice to use the same password on multiple sites because of credential stuffing. Even if the sites are not important to you, the data the website has about you might be interesting to others. Combining personal data can also be very powerful for someone who wants to do harm to you.

I don't think Bruce Schneier means he uses the same password he uses on multiple sites for his banking account, because that would be outright ridiculous. I do however still think the above applies to 'non important websites'. You also have to take into consideration that Bruce Schneier is a security professional and is well aware of potential risks in certain services. People who are not so aware might not consider their email an important service for example, yet it most of the time holds the access to a lot of other websites because of the Forgot your password feature on a lot of websites.

The same applies to storing your password on paper. Bruce Schneier is a security professional and can take certain risks because he is aware of the potential damage and can actually make well informed choices. Writing passwords down on paper should be considered a bad security practice for most people, keeping the paper in your wallet included.

Therefor I do not agree with the advice for Bruce Schneier and to answer all of your questions:

  Where are the weak points in all of the above?

I answered this in the details above here, both storing passwords on paper as using the same passwords should be considered weak points.

  Why did the high reputation security expert say this, and confirm it
  by reposting it on their own website, without further comment?

Because not everyone has the same opinion, clearly he has a different believe when it comes to passwords. That is alright, as long as we all have the debate we're having on this question: What should be considered a good security practice today.

  Have I made a literal-level error in my interpretation?

I don't think you have.

  Is the literal interpretation actually not a bad idea, and if so why?

Just as with password managers, if writing down your password on paper is a better (but not perfect) practice then not storing on paper, by all means, go ahead. For example, if the alternative is using a weak password on every single service including your banking account, writing a secure different password on paper and storing it in your wallet might actually be a good idea. However using a password manager would be even better.

  Is there something particularly unusual about my own situation?

No, I lose my wallet all the time and being a critical thinker, especially when it comes down to security, is a good habit.

  Should I consider that the "News" tab of schneier.com (distinct from
  the "Blog" tab) cannot be trusted in the same way as the rest of the
  site? I.e. could this be Schneier re-posting a news article that
  favoured him, without reviewing the post for the implication of rather
  bad ideas?

I don't think you should necessarily, but that of course is up to you. Bruce Schneier also has good advice and he is still well known and widely respected. Re-posts on a website like this should be more trustworthy then some other sources, but always, like you did now, be criticizing articles to see if it is trustworthy. So yes, this could have been a re-post without reviewing the implications, although I do believe this is not just your job: It is the job of the re-poster, in this case Bruce Schneier.


How to keep using Java 6 securely, despite its unpatch vulnerabilities

Your organisation might want to subscribe to Java for Business:

  With the announcement of Java for Business customers and partners running Java applications on older release families (1.4, 5.0, 6) now have a choice of either migrating to a newer release or subscribing to Java for Business to continue receiving critical reliability, availability and security updates, as well as new operating environment support for their existing applications.

(http://www.oracle.com/technetwork/java/javase/training/index-jsp-138092.html)


Do all non-CA certs have to be End Entity certs?

"End Entity" is defined in X.509 (well,RFC 5280) as:

 end entity: user of PKI certificates and/or end user system that is
             the subject of a certificate;

but the expression really makes sense in the context of path validation: an "EE" certificate is called that way because when it appears in a certificate path, it is necessarily at the end of the path. In that sense, an "EE certificate" is a certificate that either does not contain a Basic Constraints extension, or that contains such an extension with the cA flag equal to FALSE.

Now you can validate a CA certificate by putting it at the end of a path, in which case that certificate, though it belongs to a Certification Authority, can temporarily be an "end-entity certificate", depending on how you interpret that expression. The relation goes in the other direction: as per the path validation algorithm (specifically section 6.1.4, step (k)), for a certificate to be able to appear in a valid path at any place other than the end, it MUST be a "CA certificate" (meaning here "a certificate with a Basic Constraints extension with the cA flag set to TRUE).

This answers your question: if a certificate is not a "CA certificate" (as in "certificate tagged as being 'CA'", as opposed to "certificate owned by an organization that is also a Certification Authority"), then it may be used only as "end entity" within a validation path.

(Or, said otherwise: don't try to read too much in some ill-defined terminology. In practice, what matters is what implementations do, i.e. the path validation algorithm.)


If you're looking for signed binaries you may find elfsign and elfverify to be of interest to you. This doesn't provide a tie in for the linker. It's a manually process that writes the signature into the ELF header. Additionally, I would suggest checking out the kernel's IMA appraisal extension.

See also,

2013 Signing ELF binaries
2012 IMA appraisal extension


Why does ebay prohibit certain characters in password strings?

Is there any sane reason for enforcing rules like this? Or is it just
  stupidity on their side?

Not really it's just regular input validation. Probably they made a list of characters commonly used in XSS or SQL injection attacks and blacklisted those.

  Is this a sign that ebay uses some strange password storage method
  other than hashing it?

Not really.


Protect database data from everyone, including sys admins, etc

In order to make a live database that encrypts its data, the database itself would have to have access to the keys. By that token, any admin could su into the account and find them. Your concerns are valid.

Your idea of having the user present a secure key (RSA for example) if you have them do it over an SSH or SSL protected connection is not a bad idea. @Eric G mentioned Mylar in the comments below which does this type of thing, and more. It would be well worth examination.

If instead of encrypting the database, you encrypt the data before it gets entered into the database, then you would have a different possibility -- this is meant as a possible alternative only:

The data be encrypted before posting, and decrypted by a client program afterwards. The database would not be encrypted, only the data within it.

...or for the truly security paranoid-- do both: database encryption and data encryption, each with different methods.

More is described and discussed below in comments.


Is it OK to create a new SSL certificate before the old one expires?

Yes. There is nothing to technically prevent you from doing this. And if you are large company, then you may want to do generally do this as an insurance against CA-failure. If for example your CA of choice is hacked and suddenly revokes all its certificates, then you can just deploy the other certificate (from another large CA) that you have lying around for just such an unlikely event. (For example if you are FaceBook, you may want something like this.)

So, is it okay if I would now renew a certificate that is still valid for half a year or so?

If you want to warn people not to use this certificate anymore, then you should pay for revocation.
Expiration is the implicit "Don't use this anymore"-rule. Revocation is the explicit "Don't use this anymore"-rule.
Example: If your server was hacked, then you should consider your certificate's private key stolen. Then anybody who afterwards still encounters the compromised certificate in the wild should be warned.
Otherwise (if you can also vouch for the safety of your offline archival) then you can just let the certificate expire.
UI override for expired. But not for revoked.
Expired certificate errors are displayed differently in browsers. For example Google Chrome will currently allow the user to manually override an expired certificate warning. But it will NOT allow override for an explicitly revoked certificate.


How to securely insert JSON objects into javascript, DOM content and html elements attributes?

Some of the points that you should take care are: (in no order)

Untrusted user input should only be treated as displayable text. Never treat untrusted data as code or markup within JavaScript code. HTML encode all user input.
Always JavaScript encode and delimit untrusted data as quoted strings when entering the application
Avoid use of HTML rendering methods
Use document.createElement("..."), element.setAttribute("...","value"), element.appendChild(...), etc. to build dynamic interfaces. Dangerous attributes include any attribute that is a command execution context, such as onclick or onblur.


Is this an error message?

No, its not.

  What would it mean ?

close_notify alert is the normal way to stop a TLS session which should be done before closing the underlying TCP connection.
See also RFC 5246 7.2.1 Closure Alerts.


Are USB thumb drives inherently more dangerous than other removable media? Why?

There is at least one specific risk of USB drives which doesn't apply to SD cards, CDs and the like. An SD card, a CD, etc. are unmistakably storage devices. In order to cause harm, the user has to not only insert the storage device into the computer but also open a file on it in a vulnerable way (run an executable, open a document in a vulnerable application).

In constrast, what looks externally like a USB drive could be any USB peripheral. It could be a wifi dongle, a keyboard/keylogger, a USB-to-Firewire converter (which may allow arbitrary device-initiated direct memory access, … Even if the device appears to be a storage device, it could contain a hub connecting both a legitimate storage device and a malicious device.

So if an employee picks up a USB drive somewhere (in the parking lot, or even in a store) and plugs it in, there is immediate risk. If an employee picks up a CD somewhere and inserts it in, there is another line of defense (if imperfect).


Server authentication may help against phishing. For example, if you're going to https://bank.com and you're lead to the phishing site https://b4nk.com, both with valid server certificates for their URL (server is authenticated as bank.com and b4nk.com respectively, so we only know that the site corresponds to the URL, which most people overlook).

A petname system (documented here and here) can be set in place, so that the user upon registration associates the target web site with a petname (either a string of text, a recognizable picture or a sound). This petname is presented the user upon accessing the site. If the petname cannot be found, the user will be alarmed and should check the URL. If the URL is correctly entered, the site is safe.

Edit: note AJ Henderson's comment below.


Is allowing root login in SSH with "PermitRootLogin without-password" a secure method?

This is a common misunderstanding for the PermitRootLogin feature. The without-password option does not mean there is no authentication and anyone can get in without a password. All this option means is that logging in is only possible using a fallback method, such as public key authentication. Even if an attacker knows your root password, they will not be able to log in unless they have your private key.

It is actually better to use without-password if you need to log in as root, since it ensures that the root account cannot be brute forced. If you were to log in as root with a password, it could be subject to being remotely attacked, whereas public key authentication ensures you can only log in with the proper credential files. This is better than logging in as a different user and using su to elevate to root, as a compromise of that other user would result in a compromised root, since the user can monitor any keystrokes entered into its shell. This is explained in detail in the answer to Which is the safest way to get root privileges: sudo, su or login?.

If you do not need to have root, then using another, dedicated user would be fine. In this case, setting PermitRootLogin no would be beneficial, as there is no reason to have root access if not required.


Evaluating the security of home security cameras

Like most embedded hardware (routers, etc), their firmware often sucks, and unless you have unlimited time I'm afraid there is no way to thoroughly check every single camera out there. And even if you do find one that's currently secure, what guarantees that you'll get updates for vulnerabilities that will be discovered in the future ?

Instead, I suggest just creating your own IP cameras by using USB webcams (or cheap/insecure IP cameras) and connecting them to a Linux/BSD computer that will actually handle all the authentication/security and then rebroadcast the camera's video feed (preferably over something secure like HTTPS). That way the internet-facing part of your home-made "camera" can be updated and hardened just like any computer, and behind it you are free to put any camera you want, including the cheapest garbage since it won't be exposed to the Internet anyway.

Finally consider putting the camera system on a separate network air-gapped from the Internet - I know it doesn't apply in your case but I'd still like to mention it - the requirement for physical access is a pretty good security measure, as someone who wants to spy on you now has to physically break into your home rather than being thousands of miles away. If off-site recording is required, video could be encrypted and then streamed outside of the air-gap via a one-way Ethernet cable with the key kept securely, so that the data leaving the air-gap is meaningless unless the correct key is provided.


Does QUIC really solved IP spoofing problem

But can't the attacker just IP-spoof the initial connection? Wouldn't that achieve the same effect of IP spoofing of DNS or NTP server?

The problem with IP spoofing in DNS or NTP is not that the reply will go back to the spoofed IP address instead of the real sender because this is also true if you spoof the IP address in a TCP SYN. The problem instead is that often the response is much larger than the request and thus an attacker can use a small bandwidth with spoofed IP addresses to cause a large bandwidth attack against the spoofed IP (i.e. amplification attack).

TCP solves this problem by having only a small response to a small request so that nothing gets amplified. Unfortunately I cannot easily find information about the actual size of the source address token in QUIC but I hope that amplification attacks are considered.

EDIT: thanks for paj28 to point to an article where the problem of amplification in QUIC is addressed in more detail: ...the client hello will always be larger than, or equal to the size of the server response.... This means that amplification attacks as the main problem of IP spoofing will not work.


How Can I Tell With Certainty If My iPad Has Been Hacked?

Set up a trap

This requires some social engineering:

Send an e-mail with a shortened link to a mail adress you suspect of being monitored (you could use https://grabify.link/ for instance), make it intriguing.
If your mails are monitored chances are good that your attacker will click on that link, to see what information you want to share.
Via the tracking tools of your chosen link shortening service, you can now track the IP adress of everyone that clicks your link.

While this might not fix the security issue on your iPad, you might get an idea if your device has been compromised.

EDIT: I have not tested grabify myself and cannot vouch for its trustworthiness.


The ElGamal asymmetric encryption scheme can be adapted to elliptic curves (indeed, it works on any finite group for which discrete logarithm is hard). However, this means that the data to encrypt must be mapped to a curve point in a reversible manner, which is a bit tricky (that's doable but involves more mathematics, which means increased implementation code size). Since most of the time we use asymmetric encryption, we actually want to encrypt a session key which will be used for symmetric encryption, Diffie-Hellman key exchange on the elliptic curve is already fine, and simpler (that's what ECIES is: Diffie-Hellman then symmetric encryption).


Does SSL/TLS (https) reveals your IP address?

Any website owner can see what IP address is doing things on their website. This applies whether HTTPS is in use or not.

Any node operator (ISP, CDN provider, gateway operator) can see traffic passing through the nodes they operate. They can see both the apparent source of traffic, and the destination - they need to in order to be able to correctly route the data to the destination. This applies whether HTTPS is in use or not. They can't see the specific pages you visit, if HTTPS is in use.

Therefore, if the NSA wanted to see what a given IP address was doing, they could look at the data on a node which all the data from that IP passes through, and see what server you are connecting to. In order to find out precisely what pages you visited, they would need to look at the data on the web server, or on your machine. They could do this whether HTTPS was in use or not.


Does CSRF work if your browser has stored cookies?

Though there are some details that impact this, going by the general principles, the answer is YES.

An attack exploiting CSRF would attempt to execute some function of the target site (facebook, in your example) in the browser context.

So the key test is: If you open facebook in a tab (in the scenario you mentioned), would it give you a logged-in session directly. It appears that it would. In that case, it meets the conditions necessary to mount a CSRF attack.

There are many nuances. For example: Vulnerability != Exploit. i.e., though the attacker may get CSRF to work (and produce a POC to get a bug bounty or complete a VA/PT assignment) - there may be nothing there to exploit due to other protections. e.g., if additional auth is required to really do any damage.


Understanding Session Fixation Vulnerability

The attacker never logs into the site with their credentials, they just access a page to get the session id, so while they pass on a valid session id to the victim, they do not pass on an authenticated session. When the victim logs into the site, the session is now authenticated and the attacker can access it as the victim.


Why do outgoing rules have priority over incoming rules?

Your firewall configuration on the router is a stateful one.

When an outbound connection is established, the router/firewall keeps track of the connection and allows any response over the same connection through the firewall.


For posterity and folks who end up here from search engines:
Amazon SQS now supports content encryption: https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/sqs-server-side-encryption.html#sqs-encryption-what-does-sse-encrypt
From the documentation:

SSE doesn't encrypt the following:
Queue metadata (queue name and attributes)
Message metadata (message ID, timestamp, and attributes)
Per-queue metrics

SQS server-side encryption is backed by Amazon's KMS by default, which are themselves backed by FIPS 140-2 HSMs. Data keys are derived from an account master key on a per-principal basis.  Lifetime of these keys is configurable from 1 minute to 24 hours with a default of 5 minutes.
If key residency is not an issue, SSE should solve your problem.


So, to start, let's look at the architecture. Many VPS providers aren't good about this, but if you can communicate between your VPS' on an internal network using private IPs, that's preferable. Digital Ocean will let you do private networking and accomplish a lot of the inter-connectivity without traversing the public Internet. If you can do this, you'll remove a ton of attack surface by limiting potential MitM attacks and making IP spoofing untenable (or at least less-tenable) from the Internet.

Next you would want to avoid having to expose the API server to the public Internet (or at least I would). The kubernetes API server is fairly robust and uses reasonable authentication, but it presents a large attack surface and potentially large damage if it's compromised. So I'd recommend having a Bastion Host or VPN server that allows you to connect into the kubernetes environment where you can administer your cluster. Just don't store any authentication mechanisms on this bastion hosts, make it a dumb jump-box in  case it's compromised.

To avoid exposing all of the nodeport services, you can use a Load Balancer, if your VPS provider has one, probably you should use that, otherwise a dedicated nginx box would be best. However, for tighter integration, you might expose 443 on each of your worker nodes and use the nginx-ingress controller on the cluster itself, this way you can use a lot of the built-in integrations, but still control what services are externally exposed.

Once you have those two things taken care of, you could probably get away with just allowing all traffic between your kubernetes nodes within the cluster. But it would be better to batten the hatches as it were.

Let's define the servers/VPS into the following groups

Etcd nodes
API Servers
Control plane (all of the Etc nodes, schedulers, controllers, api servers)
Worker nodes
Bastion Host
Load Balancer

you would want to implement the following rules using UFW and (if it exists) your VPS' security groups/cloud firewalls/etc. These rules assume a stateful firewall like UFW or AWS Security Groups. If you're using AWS Security groups, you can have named security groups for each of the above groups and have them reference each other and not specify IP addresses at all. Using UFW, you will have to list IP addresses.

Control Plane and Bastion Host -> API servers over TCP/6443
Etcd and API Servers -> Etcd Nodes over TCP/2379-2380
Load Balancer and Worker nodes and Control Plane -> Worker nodes over TCP/30000-32767
Control Plane -> Control Plane and Worker nodes over TCP/10250
Control Plane -> Control Plane over TCP/10251-10252

This could be broken down further, but I think this is a reasonable configuration. I don't think the Control Plane needs access to the nodeport nodes, I don't think the etcd cluster needs access to the kubelet, and so on. Proceed down the rabbit hole as far as you like. To lighten up the security posture you can expose the nodeports and the API server to the world, just make sure you understand the ramifications of doing so.

Attacks against this architecture

As you mention, if your cluster is talking over the public Internet, anyone can identify themself as a whitelisted IP address. Suppose an attacker sends a request to Etcd at 120.88.41.177 and says that their IP is 120.88.41.176, but their real IP is 120.88.41.175. The request will bypass UFW just fine, but the server will also send the reply to 120.88.41.176 and not to the attacker. Unless the attacker can intercept the traffic, the attacker never can see any of the replies.

Also, for this to work, the IP addresses of your servers would have to be known to the attacker (which may or may not be a tall order).

Next, the cluster-level communications (Between the Kubelets, API servers, Etcd cluster, controllers, and schedulers) all run over HTTPS by default, using client-side TLS authentication. (EDIT It looks like Etcd with authentication is not support by default as of k8s 1.17, so limiting network access to Etcd from ONLY the API server(s) is very important). So in order for the attacker to communicate with anything within your cluster, they also have to compromise your CA or a client key somewhere in your infrastructure. At which point, if an attacker compromises a client key, they probably have some access to one of your nodes and the network security is moot.

This is why I would suggest some variation of the above suggestions for your network, and then focus your efforts on good RBAC controls to limit what actions each pod can do, and limit what actions each node can do. Or add some network policies within kubernetes to limit the access of the pods. At the host/VPS level, the networking is pretty straightforward, the API server has to be reachable by all of your nodes, so you can't really protect against a compromised node/pod using UFW.


How to protect UEM (Unified Endpoint Management) agent on your endpoint

I have read a few things about that in the past few days.. came up with some ideas.

Ensure you have authentication used on the application. This can prevent someone from killing your agent AND create a fake agent to talk to the server. They will need to authenticate with their fake agent first, if they dun have the credentials, they will not be able to do so. You can also implement 2FA / U2F to increase the strength. This eliminated the possibility of your process being killed and create their own session.
Use TLS for connection, this might sounds lame, but it is an effective solution to prevent MITM attack, so in this case, we can prevent the attacker from changing the traffic.
Get your application signed by Microsoft / apple /google, and leverage their protection mechanism in the operating system to protect your app from being patched in runtime. Please look at system integrity protection in MacOS. This prevents your process from being touched even they gained root access on the device/platform.

By combining all three things, I think the attacker will not be able to modify the app/traffic. Let me know if you have any ideas!


How does anycast ensure reliable delivery of IP packets for the same IP address on different locations?

It is counter intuitive, but various providers have talked about their experiences over the years and going back as far as 2 decades have shown Anycast to be at least as stable and often more stable even for TCP/HTTP traffic than Unicast.

Why is this-

To a first approximation the internet is divided among Tier x backbone connectivity providers, corporate endpoints, and ISPs serving last mile. These parties exchange traffic through either peering agreements or transit agreements. Peering agreements are least cost and make sense when there is a significant flow of traffic in both directions. Transit agreements are more expensive and exist where there is an imbalance of traffic flow.

Very significant care goes into the planning of points of presence for corporate endpoints from which Anycast announcements will be made, and therefore into the peering and transit agreements by which user traffic flowing out of ISPs will reach those endpoints in a least cost manner, where cost is measured both financially and topologically.

That is, these agreements are ideally structured such that there will be a preferred least cost global route for any individual customer to a specific POP, with fallback more expensive (in both topological and financial terms) global routes to other POPs.

So the magic isn't necessarily in Anycast and BGP but in these peering and transit agreements. These allow Anycast and BGP to optimize local path decisions to deliver global topological stability over the lifetimes of relevant TCP sessions (usually at most minutes).

There is some talk of major global players like Google who play in backbone, endpoint and ISP performing their own proprietary magic TCP state replication between POPs, but that's not the common case. The common case is that network architects deliberately construct agreements that optimize for global stability.


What is the industry best practice for when 3rd parties are hit with ransomware?

I'd say it is overkill, since you're going to be exposed to the Internet and external connections and thus be constantly under drive-by attacks or targeted.  However, it is certainly a good idea to consider the vendor 'higher risk'.

Regular security reviews should always be undertaken and the principle of least privilege is definitely something which should always be considered during this.  As a first step, all credentials and keys should be immediately revoked, and should not be re-enabled until an audit has taken place to prove there is no infection or unauthorised access to the vendor.

The vendor having VPN access to your network and the risk that exposes you to could vary massively - it might be access to your internal website through to control of critical infrastructure.  If it's the latter, then you should certainly consider curtailing that, monitor the systems closely, and not allow access again until a full independent audit has taken place.  If it's just read access as a non-privileged user then the risk is minimal, apart from of course information leakage, unless there is serious issues in server infrastructure.

I would not allow any file uploads from the third party again until that audit has taken place - you should already be scanning the uploads though.  I would also take the opportunity to examine what protocols they do have access to; is it just SFTP, or are there shared hosting services like Dropbox involved, and if so, why?

I would also require all e-mails for some time to be passed through and signed off manually by IT administrators before being forwarded to their final destination.

If this was a company involved in any way with my IT infrastructure and network I would immediately be looking for a replacement vendor in the medium-long term.  From a business perspective, you mention there is lost business associated with cutting off this vendor but all the above will also cost money and time to implement.  That figure of course depends on how good your existing policies are - if I'm setting something up there wouldn't be much to change ;) !


Does ISO 27000 certification increase the risk of being attacked?

I do not see an increased risk of attack due to being an ISO certified organization.

ANSI (The governing standards body) does not release ISO certified organizations business names.  There are organizations that offer you the ability to look up an ISO 27001 certified organization but those organizations have elected to register voluntarily.

I would suspect that another driver (high cost, large time footprint, operational workflow implementation) is behind a lack of desire to become certified.


When automatic login may be acceptable from the point of view of security?

We would need some more information on your use case. Is this a kiosk computer?

In this scenario you no longer have the ability to tie specific actions to specific users. Furthermore, users may accidentally leave information which is exposed to other users unexpectedly/inappropriately. Another user may also do something malicious while they have access and this would easily impact the next user.

A lot will depend on your situations. Perhaps it would be acceptable to have some sort of automatic login with a badge or smartcard without and additional password authentication on this machine - thus, each user still have a separate session.

You might also want to look into some controls to wipe back to a clean state and to force a maximum session. This would help to address the risk of one user doing something malicious which will impact the next user or the first user accidentally leaving confidential information which the next user should not see.

There is software like Deep Freeze that can provide some such features. You may also want to use some type of thin client setup that only goes to a Citrix session on a VM that you can easily roll back to a point in time.

While the actions the user is intended to do are low, the risk is still high in the actions the user could do. You can balance the risk with some processes and controls.

Note just running a system in Kisok mode without rebuilding to a clean state is not sufficient, as the user may modify the browser or find system artifacts, even in a locked down browser using a privacy/incognito mode.


Is SSL/TLS Sufficient For Safe Transit of Bianry Data via API Traffic

This question can be rephrased as: Is there a situation in which the attacker can compromise TLS, but not additional encryption? The answer lies in the implementation of either system.

  The API will be using the HTTPS protocol, but management thinks that is not sufficient and that we need to encrypt the data itself before it is sent.

Management always seems to think that more is better, but you have to think about where the keys are in order to develop a threat model. Are the servers which have the data the same servers that are establishing the TLS connection? If so, then encrypting it before being sent would provide no benefit, since a compromise of those servers would simultaneously provide both encryption keys.

  Is SSL/TLS sufficient for safe transit of the file?

Assuming it is properly configured, it is safe and sufficient. You want to select a secure cipher suite. There are online guides for selecting a good TLS suite. For an internal API, not all of this is needed, as you can act as your own CA safely.

  Does HTTPS/SSL protect binary data or just plain text?

In the HTTP protocol, the only thing that hints at the type of data is the Content-Type header. This header tells the end application how to interpret what it receives. TLS operates on a layer above that, and as such the encoding is irrelevant. It blindly encrypts all data, including headers.

  Does the length of time that it will take to transfer a file of that size pose additional security risks over plain text?

The amount of time it takes to transfer data over TLS does not impact its security. No modern cipher is going to weaken just because you are encrypting a large amount of data. TLS is fast enough that, on all but the oldest hardware, it will perform equally well as a plain connection.

  Is the concern with the additional layer of encryption justified?

Assuming your network topography is such that TLS will provide end-to-end encryption, then no, there is no justification for additional crypto. The added complexity may introduce bugs. If you control both servers, you can use a self-signed certificate and verify the fingerprint, so you do not need to rely on a CA for authentication.

In other words, the only time that it would not be sufficient is if any of the following is true:

There is a weakness in the design or implementation of TLS.
A feature you require is not present in TLS.
There is a situation where an attacker can obtain the TLS key without obtaining the other key.

If none of these are true, then TLS will provide three primary guarantees:

Authentication - You can be sure that the connection on the other end is who they say they are.
Integrity - In-transit data cannot be modified without the other end being aware of it.
Confidentiality - All traffic will only be readable to intended parties.

Extra encryption using GnuPG for example will provide no additional guarantees.


The idea of password storage is to make it as hard as possible for an attacker to get it because you can't ever stop them from getting it altogether. You are correct that hashing is not what you want because hashing is making sure that 2 inputs are the same (i.e. useful for verifying that a user knows the password), not for storing passwords in the way you are talking about it.

What I would do in your situation is one of two things:

Try to remove the need of the passwords, can you log in manually and then keep the session key alive or have it so the program looks at a password file that you then delete (remember saved files leave ghosts of themselves, so maybe have the file on a usb stick that can be destroyed if you are that security conscious)
Protect the password file, this can be done using the user access
stuff on Linux (make it read only for only the user who is running
the program and then have good password on that user account) but
you should also have some encryption over the file too because user
access can be gotten around by manipulating the storage media
directly. I can't help you with suggesting encryption methods but it
would be something you would enter a password to decrypt so the
program can read it and put it into memory. An SQLite database would be one way to get access control and encryption with (relatively) little setup.


is it safe to allow external images to be attached to Blog or any Web content?

If its just a simple profile picture,  you can avoid most security threats by using a trusted 3rd party like Gravatar(which is what security.se uses).  Using a linked image as a "Web Bug" are unavoidable with remote images but apparently a lot of people don't care that Gravatar can track them.   Storing an attacker-controlled file locally creates other security threats.

More generally,  you do not want to store user-controlled files on your server.  A good example of exploiting this type of vulnerability is using a PHP local file include (LFI) vulnerability to obtain remote code execution.  Even storing an attacker controlled file temporarily is a security threat that can be exploited with an LFI attack.

Verifying that the link is in fact an image using getimagesize() helps prevent CSRF.  However,  even a valid image file can contain PHP tags in the EXIF metadata,  and that could be used in a LFI attack.   LFI attacks like this can be prevented using PHP's open_base_dir configuration option to prevent PHP from including files in the image or temporary directories.


When does iOS check validity of enterprise certificates?

From the iOS 7 Deployment Technical Reference document (opens a PDF):

  Certificate validation
  The first time a user opens an app, the
  distribution certificate is validated by contacting Apple’s OCSP
  server. Unless the certificate has been revoked, the app is allowed to
  run. Inability to contact or get a response from the OCSP server isn’t
  interpreted as a revocation. To verify the status, the device must be
  able to reach ocsp.apple.com. See “Network Configuration
  Requirements,” earlier in this appendix.  The OCSP response is cached
  on the device for the period of time specified by the OCSP
  server—currently, between three and seven days. The validity of the
  certificate isn’t checked again until the device has restarted and the
  cached response has expired. If a revocation is received at that time,
  the app is prevented from running.  Revoking a distribution certificate
  invalidates all of the apps you’ve signed with it. You should revoke a
  certificate only as a last resort— if you’re sure the private key is
  lost or the certificate is believed to be compromised.


What's the optimal length for the row level IV? Is 256 bits fine?

The answer depends on whether some of the plain text will be known or can be easily guessed by the attacker.  The question described the data as, "Highly sensitive," and the protection period of, "100 years," so use the strongest cipher and largest secret conveniently available for encryption.

  Is the minimum password strength of 19 characters and 10,000 iterations of PBKDF2 strong enough to protect the 256 bit database key? If not, what parameters would work?

The answer to the number of characters is not determinable without knowing the rules imposed on passwords during validation.

  Is PBKDF2 still a good algorithm still to use here? If not, what Scrypt parameters?

An answer exists that provides some good background on bcrypt or PBKDF2.

  Any further changes or recommendations to make the system secure?

Yes. Many. Here are a few.

Remove all redundancy that you can reconstruct in query results after decryption.
Ensure that the salt used to exhaust the block before encryption is truly unpredictable.  (Use the best entropy source you can acquire on the server.)
Separate critical payload from less critical payload if they can be statistically independent to reduce the memory footprint of the plain text versions of the critical data.


SOP for the CERT in case of hack activity

From what I understand you already have in place policies/procedures and all that stuff.

My advice is to take a look on Time Based Security (was written in 1999, but still gold).

The main formula for Time Based Security:

Pt>Dt+Rt

  If the amount of protection time (Pt) you offer is greater than the
  sum of the detection time (Dt) and reaction time (Rt), then your
  systems can be considered secure.

Based on that, try to improve your defence :),

Over the years, I realise, not only good firewalls or IDS can help me for a good security. An analytical thinking also help a lot, you just need to step back and look at what happen and try to see what you can improve. From my opinion a BIG percentage of the security problems are in procedures/policies and not on your firewalls/IDS.

https://www.hackinparis.com/slides/hip2k12/Winn-Keynote.pdf


What is the purpose of enclosing process spawning?

Any serious virus probably wouldn't want to bet on the victim having all those languages installed. The script doesn't appear to be malicious at all, I ran it in a VM and it went about as expected. Its almost certainly some kind of joke.

The filename is the sha512 hash of an empty string (checked here).


How can brute force scripts tell once they're found the correct key?

In a case where the encrypted data is completely random it could be fairly difficult to tell whether decryption in a brute-force attack has been successful, however real-world attacks are unlikely to be against completely random unknown plaintexts.

Generally it's possible to tell that you've decrypted the data because the result is something which has a meaningful pattern (e.g. has dictionary words in it).  So a script can test for whether there are meaningful words or other patterns known to be present in the plain text data to tell when they have successfully guessed the key.


How to implement TLS in a product with complex distributed architecture?

... achieve 2 way mutual TLS authentication in this case without installing TLS key pair
...

Obviously you cannot do authentication with a client certificate without having a client certificate installed. But you basically face the same problem with any other authentication method: if you want to authenticate each agent then somehow you have to setup each agent with agent-specific credentials first and also associate these credentials with the agent in the scheduler. It does not matter if these are tokens, passwords or key pairs.


Ports Showing Closed/Filtered in Nmap Scans

To avoid 65K+ lines of mostly-useless output, Nmap collapses most "uninteresting" results into a line that says something like "Not shown: 65530 filtered ports." Open ports are never collapsed this way, but closed (TCP RST) and filtered (no response or ICMP admin-prohibited) ports are only shown if there are fewer than a certain number.

In your case, I would guess that most of the ports are "filtered" but a few are "closed" instead. There are many reasons this might be the case, but the most likely are:

Something between you and the target is blocking access to those ports by spoofing RST replies. This is common with residential ISPs blocking ports 137, 139, and 445, among others.
The target's firewall is allowing those ports, but there is no service running on them.

EDITED TO ADD: Based on the actual port output, I'm pretty sure this is ISP filtering (spoofing closed-port responses). Ports 17 and 19 are commonly used as DDoS amplifiers (though UDP, not TCP). Ports 137-139 and 445 have been exploited on Windows by network worms. Port 25 is for email servers, so ISPs block it unless you buy a business-class connection. I'm not sure about 111 and 136; those could be legitimately closed, or they could be blocked for some other reason. Add the --reason option to your scan to see details about IP Time-to-Live (TTL) in the response; abnormally high TTL values can indicate ISP blocking, especially if the TTL value for open ports is several hops lower (usually between 5 and 15 hops different or so).


How easy is it for hackers to gain unauthorized access to resources on an Android phone?

(Difficulty: Incredibly Easy): If you're in Developer Mode, many of the restrictions in place to keep you safe are missing. This makes it easy for developers to test apps, but makes the device incredibly insecure. Thankfully, turning on Developer Mode is non-trivial in newer versions of Android (just a few years ago, it was not much more than a checkbox in the main settings menu). This mode should always be disabled on hardware that contains any data you care about.

(Difficulty: Easy): If you allow installs external to the Play Store, it's possible to spoof permissions due to various glitches in the permissions API. Without using the Play Store, your device can install non-Google managed software, including malicious software that can be linked to from a normal URL. It's also possible make a "no-permissions app" that later elevates its permissions through a stack overflow/underflow or buffer overrun/underrun exploit. I don't know of any specifics about those types of vulnerabilities, but I would presume that such attacks are possible.

(Difficulty: Moderate/Dependent): Some devices are "rooted" by the user, which is necessary to install some classes of apps that are not ordinarily allowed. This bypasses many of the restrictions that Linux provides, because the user is now logged in as "root", giving superuser access to the user and all apps that they install or run. Many people don't realize this is a bad idea, and so are later surprised to find out their device was compromised simply because they gave the primary user account elevated privileges (translation: they didn't know what they were doing, and what the risks were).

(Difficulty: Hard): Otherwise, if you're not in Developer Mode, and you're not allowing external installs, and you haven't rooted your device, there are vulnerabilities that exist in various scripting engines that are used by the Play Store and other apps. These can be exploited through UXSS (Universal Cross Site Scripting) attacks, where the main installation intent is invoked without the usual permissions dialog, and the only thing that's necessary is loading the script in memory through a link in a message or email. For example, Android Jellybean and lower could be hacked this way. Never trust links from sources you don't trust, and consider installing security software to reduce the likelihood of unwanted installs. NOTE: As far as I know, most apps automatically attempt to invoke an intent rather than check for some arbitrary notion of security. That is, the browser doesn't know if you meant to install an app, but it looks like you did, so it sends this request to the installation intent/Play Store.

Note that this isn't unique to Android, as iOS, Firefox OS, and Windows Mobile all have potential vulnerabilities, especially if "rooted" or otherwise modified than ways that were intended. It's also possible that carrier-provided software (those annoying apps you can't uninstall) could also have vulnerabilities, and you might not even be able to uninstall or disable those apps.


How to distinguish between "normal internet" Port scan and more "serious" port scan preparing attack?

You can't because there isn't one. Unless a port scan is:

Initiated by you.
Initiated on your request or behalf by a security partner.

It is malicious. You can block them as you wish. The sole purpose of port scans, malicious or not, is to find weaknesses and vulnerable services in your internet facing gateway. If you or a partner does it, it's to help you strengthen your posture. If anyone else does it, it's to determine if you're worth attacking, and how to best launch that attack.


Where are the user credentials stored when remember password is selected?

Usaually the user's browser stores some cookies with a random string identifying the user on the server.
More secure variants of this additionally check other parameters as the browser version, OS of the user and approximate location.

Basically, if you visit a webpage like facebook with a cookie, you get authenticated only with the random string in the cookie.

How this works:
If you log in, the server generates this random string and stores it in it's database (togehter with other identification parameters). Additionally it sends this string as a cookie to the user's browser, where it is stored and delivered to the page with every request.
So if there is a request with a random value, the server checks if it matches with the other identification parameters and - if so - accepts you as a logged in user.


How to refuse delivering emails that are not signed by trusted PGP keys?

Any Unix MTA can pipe mail to a script. Run signature checks on the server and if the script returns true, pass the mail on. See your favorite MTA's documentation for an explanation of how. This is the same kind of setup used to create listserves.


TPM based authentication without a trusted third party

TPM operations which need the EK:

Take the ownership
Clear the TPM
Change the SRK
Change the Owner(obviously)
Allow SRK read using SRK auth (tpm_restrictsrk -a)
Basically, these are all administration operations.

The root key for the AIK is the EK. The goal of the EK is to prove everything we send comes from a valid TPM. So yes, you can use your EK to sign, but there will be a privacy issue: everytime you use your EK, you will be traceable. That's why the AIK was created, to prove you are a valid TPM without getting traceable by anyone(Well at least by the CA, and that's why we use DAA).

Your forth question is interesting because you aren't the first one to ask it. Therefore the TPM 2.0 specifications separate all these operations. There is the endorsement hierarchy (administrator who manage the privacy domain), the storage hierarchy(user who manage the security domain), and the platform hierarchy(platform which can deny the use of the other hierarchies).

Obviously, the Endorsement Hierarchy may generate Endorsement Keys which you can use to sign your datas.

For more informations you can check this pdf


Do I need high password security if I also require a Client Certificate for validation?

You do need a proper password hash (slow and salted — iterating is one way to make it slow). It doesn't matter that the user has a second authentication factor such as a certificate. Hashing the password doesn't protect against the same threat.

Using a second authentication factor protects against someone guessing the user's password on your site, or obtaining the password by snooping on communication, by shoulder surfing, with a keylogger, etc. The protected asset is access to the user's account. For that purpose, the way your server stores the password is irrelevant.

A proper password hash protects the password against an attacker who gets access to the password database on your server (or a backup). The protected asset is the password value, which the user may have used on other sites. For that purpose, how the user authenticates on your site is irrelevant. Your server could even store a password hash that it doesn't use to authenticate the user (for example, if you're running a proxy authentication service), and it would still need to store the password securely.


You do not need apps to keep track of calls and GPS position.

For most carriers, all calls are shown in the statement and most update this every few days or more often in the online view. For any line you can see what number was called and for how long. Since this information is coming from the carrier, you do not need to worry about anything being deleted by the child. If you pay the bill, you get to see this information for all lines on your plan. In most cases this will also show you who SMS/MMS were sent to, but not the content, and not email information since that is not a carrier service.

As for GPS tracking, you do not need an app for that. This is something which can also be done through the carrier or through third party GPS monitoring solutions for a fee. In most cases, this requires an opt-in, but since you can take your child's phone from them and opt-in, you will be able to do this. For example, on Verzion there is Family Tracker, which even lets you setup geo-fenced alerts. There are also third party services which provide opt-in tracking.

It is not usually illegal to install software to track and monitor your own property, and in many cases it is okay for a parent to track their child in such a way. For legal concerns though, please ask a lawyer as I am not a lawyer and therefore cannot provide legal advice.

With any type of app or local tracking, a smart kid will always be able to figure out how to disable the tracking or to send false data so any app has a likelihood of being circumvented. There are also alternatives like Google Voice, email, etc. or some encryption services that those who want to make it difficult will use. Likely, the best response would be for the parent to develop a trusting relationship with their child and to keep up with what they are doing and where they are going.

Something you may want to research more would be working on a rooted phone. It may be possible to password protect access to the rooted controls and you may be able to put something there and have it be hidden from the user mode apps since you are doing this as root. You would of course have to root the phone. A quick search shows at least one example of a GPS app that can installed as a service with root in the background. I am sure someone makes such things for call recording, logs, etc as well which might be worth further research.

Since you wanted more information on India, it looks like perhaps you could ask the government, as there are plans to track all mobiles in real time. At least for a kidnapping or runaway I would imagine the police could leverage this, later to dinner, probably not.


Do we need to guard against federated identity servers lying about who signed in?

You have to indeed no technical way to verify that a federated identity provider actually verifies user identity on authentication (e.g by requesting username and password).
You may audit and test the provider. The provider should state how users are authenticated (e.g. username and password and a second factor in addition). You may be able to check that with an own user account at the federated provider.
Alternatively you could ensure that users from a federated provider do only get access to resources which are owned by the same party. It is then in their own interest to use proper authentication mechanisms.


If you check out the IKE wikipedia page it describes how the symmetric keys are established. IKE consists of two phases. Phase one negotiates the IKE-SA which establishes a secure channel to transmit the key. The key is used to encrypt further communications. Phase 2 establishes the IPSec-SAs which contain the algorithms and keys etc that are used for the traffic that is to be secured by IPSec. The wiki page states that it IKE uses a Diffie-Hellman key exchange to create the shared secret that is used to derive the keys. Hope this helps some.


3 byte address of system call and exit call

I'm not sure what you mean with the "address is 3 bytes" (unless you're on a 24bit system?) :)  The memory addresses are probably 32 bit (4 bytes), but the addresses have probably a null byte in them, so you want a way to introduce a null byte in your shellcode.

What you can do, is a bit-shift on a register.  This will - as the name implies- shift the bits to a direction that you want; right in this case, and fill up with zeroes.  (0x11223344 -> 0x00112233)

The following code will make EAX into 0x00112233

05 44 33 22 11    add    $0x11223344,%eax
c1 e8 08          shr    $0x8,%eax

And as you can see in the hex codes, there's no null byte introduced in the shellcode.

Alternatively, you can work with lower registers (ax, al, ...) and rotate all the bits around.  Of you can calculate the inverse value using a bitwise NOT, for example: 0xffedcba9 is the bitwise NOT value of 0x00123456.  Or you could XOR 2 values to get to your address.


Shellcode as part of format string buffer

It sounds like you understand basically what you're trying to do, so this is more a programming puzzle than a security one, at this point.

  If the buffer has the shellcode placed before the %Nu%n sequence, I won't know how many characters have been printed before I get to the first %n, since the shellcode will contain non-printable characters.

Getting the length of characters printed by just treating the shellcode itself as a format string is trivial: all the *printf functions return the number of characters printed, so just running int c = printf(<SHELLCODE>);printf("\n%d\n", c); will tell you how many characters are printed in the course of treating the shellcode as a format string. However, putting the shellcode before the format specifiers like this imposes a limit on the minimum value you could put with %n specifiers after the shellcode.

  If it's placed after it, I won't know the address of the shellcode itself, since the amount of digits for each N may vary.

Easily solved by padding the string (with spaces, or zeroes, or whatever you want except format specifiers) between the format specifiers and the shellcode, and deleting a padding character every time a format specifier gets one character longer. In practice, since the number of digits in N will only change when you the value of N crosses a power of 10, you can also achieve this by just making minor tweaks.

If you want to make this really easy, pad the input string between your format specifiers and your shellcode with single-byte no-ops (the canonical one for x86 is 0x90), and then you only have to land somewhere between the end of the format specifiers (exclusive) and the start of the shellcode (inclusive), rather than on the start of the shellcode exactly. This technique is called a "NOP sled" because when the instruction pointer winds up anywhere in it, it just "slides" all the way into your shellcode.


mitigating anonymous DOS (tor combined with pyloris)

sarepta: To start off, I am the author of PyLoris, so I have done a good amount of research into this. In fact, the attack you have envisioned is one that I specifically coded to when developing PyLoris--the current version even comes bundled with an helper app tor_switcher.py which routes the attack through multiple Tor exit nodes.

The only good way of detecting a Tor-based flood is by checking source IP addresses against known Tor exit nodes. This is trivial with blacklisting or plugins like mod_security. In my research, mod_antilors does not prevent the PyLoris+Tor vector as it is IP address based. My personal choice for preventing this attack is to use any server other than Apache to handle direct connections from the internet. This could mean using a reverse proxy like Varnish to marshal requests or switching to something like nginx for your web server.

Aside from rethinking your infrastructure, I do feel that a combination of low timeouts, IP connection limits, minimum data transfer rates, maximum connection time limits, and maximum request sizes can provide adequate protection from this form of attack. I say this all with the disclaimer that there is no way to prevent this form of attack, and that these configurations should be thought through thoroughly to gauge their impact on a per-server basis.

To counter Tom Leek's assertion that Tor is not an efficient way of performing Denial of Service attacks, PyLoris and SlowLoris are application layer attacks, and are not based overwhelming bandwidth. In fact, connection exhausting methods like the one these use are one of the few techniques that work in throttled environments (see Slow/PyLoris' use in Iran's Green Revolution). At the peak of a *loris attack a server would likely experience less than 1kbps of traffic.

To counter D.W.'s reasoning, one of the big selling features of Atlas Networks' Pravail APS was the ability to prevent PyLoris and SlowLoris (explicitly stated in their earlier brochures). This attack method is less prevalent than standard HTTP floods like LOIC, but only because it is a significantly more difficult technique to use correctly.


Is risk a good way to approach this situation?

Yes, a risk based approach is always a good idea. :)

  Does my reasoning make sense? I.e. No sensitive data, backed up, other controls, etc then OK to remove the PIN

Generally, using PINs vs not using PINs depends on your threat model and a few other factors/considerations.

Consider the external factors like the location and portability of the specific devices in question, as well as the physical security level of your company premises.

Laptops which will leave company premises have a different threat model than stationary desktops.

Laptops: once the device leaves company premises, it's basically out of your reach in case something happens to it. If it's stolen, it's gone and the thief can do pretty much anything with it. This is where pre-boot PINs come into play. They would prevent an attacker from even booting the device, severely limiting his attack surface.
Desktops: if your office premises are at least somehow secured (video surveillance, night guards, alarm systems, access control etc.) your desktops are much less at risk of being targeted by attackers. An attacker would first have to break into your office to access your clients. In that case, I'd say that pre-boot PINs are not that necessary because of the limited attack vectors. Just make sure to actually secure the desktops to their desks so no attacker can just walk away with some towers in their hands.

In short: laptops = higher risk = PIN necessary, desktops = lower risk = PIN not necessary (but advised).

All that being said, I think that enforcing your "No sensitive data on non-PIN clients" will be way harder to enforce and impelent than to educate your users and raise security awareness.

You already have a bad start, because users are actively complaining about security measures. This indicates that security awareness is not high enough in your company, especially when your users already have management on their side. If your users detest BitLocker PINs that much, chances are high that they will use very insecure PINs in case they are forced to continue using them, e.g. 123456 or 0101010101.

Find out why the users are complaining about PIN+Logon password and educate them and management on the benefits of pre-boot PINs on laptops, just make sure to leave the technical side out of the discussion - management and users won't understand your techno-babble. E.g. "If it's stolen, attackers cannot harm the company. And if the company is not harmed, your jobs are not at stake. You can do your part by keeping the company safe/secure", or something along those lines.

Since your company is compliance-driven, a clear policy for home office/laptop usage should have pre-boot PINs as a mandatory requirement in them from a risk perspective. If it's part of a policy, compliance will have to enforce it.

If your management still won't budge, remember that risk acceptance is also a valid risk treatment method (if it is documented in writing! With a risk owner, e.g. the manager in question, who will take the responsibility once something goes wrong.)


If it's a 4 character password, you can do it.  If it's 13, good luck.

Rarcrack, under the GPLv2 license, is one of the few cracking packages that has a mode for 7z files at this time.

A tip from MyDigitalLife.info shows that if you start rarcrack once, then stop it, you can edit the abc element of its XML config/status file to limit the character set it searches.
If there are any characters you can eliminate, do so; it'll shrink the keyspace significantly.

If you're reading this thread after March 2014, see if there's a version of John the Ripper that lists 7z files; as of today, there is not, it's merely listed for the future (indeterminate).

Edited 2016: oclHashcat now supports 7-zip format as well, and is definitely a superior product.


I don't think the first part of the PXE boot can be secured. A rogue DHCP server could hijack your install. And TFTP offers exactly zero security.

But assuming you get a response from the right DHCP server and you pull the boot file from the right TFTP server, the configuration could direct the client to load via HTTPS, which would provide both encryption and authentication.

See, for example, this HOWTO on setting up a PXE installer. Substitute an HTTPS server in the config file given at the bottom.