How to auto renew OpenVPN client certificates using easyRSA

Since this is old, how did you solve it?

My thoughts both use a simple API to drive part of the process:

Approach 1

This can work if you have your client check the certificate, and if it's due to expire, it can ask for a new certificate. This doesn't need to be a CSR or anything, but instead a private API that can generate a new cert. You need rudimentary logic to authenticate the client before providing the new cert. Back on the client, your script can replace the certificate used to log in.

Approach 2)

This might be useful combined with an API. Setup an HTTPS API on your client, with a secret URL, where you can push new certificates. If that doesn't work, maybe have a script on your server to allow expired certificates in certain conditions.

Another Note

Don't expire your certificates and instead lean on the revocation mechanism


How to get around hard coding a PFX password

If you ask me having to update code when you change certificates is a pretty poor design, but that wasn't your question.

The only way to protect the private key from the server itself is to offload SSL operations to a trusted host. If you're concerned about the private key's safety on the server, you could get a hardware security module (HSM) which securely stores the private key and performs the necessary crypto operations in a secure isolated environment.

Honestly though, if you're not going to use an HSM you may as well store the key in plaintext rather than hardcode a password into your application because that's only the illusion of protection. Without an HSM, one way or another the server has to have the private key to operate and someone with control of the server can just rip it right out of memory if they want.


Notification or report for security problem of unix systems?

One of the services we use to track vulnerabilities is called Cassandra.

You create a profile and then tell it what servers and software you are using and it sends you notifications of vulnerabilities.


DNSSEC: Does the algorithm of the ZSK need to match the algorithm of the KSK?

It is not legal. The rules for zone signing were clarified in RFC 6840 because the original RFC was quite terse:

  The zone MUST also be signed with each algorithm (though
  not each key) present in the DNSKEY RRset.

Since both the KSK and the ZSK are included in the zone's RRset, in practice this requires that the ZSK and KSK use the same algorithm (or rather, that there is a matching ZSK for every KSK algorithm).

Note that the following paragraph explains that these requirements apply to DNS servers only; resolvers (validators) are instructed to accept any valid signing path.


Is it possible to completely obfuscate proxy servers?

Another way of asking the same thing: could a motivated fraudster completely disguise their requests, so as to appear to not be behind proxies, when really they are?

There are "residential proxy" services which basically offer routing the traffic through residential IP addresses, often by (mis)using the legal internet access of an (unaware) customer of common ISP. Properly done the traffic looks like originating from this specific ISP customer and there are no traces of proxy use.
See How to create a proxy so that no website or web service can know that I am connecting through a proxy? for more information.


How to protect against portable applications

I use programs in my computer such as the commercial Faronics Anti-Executable and the free version of NoVirusThanks EXE Radar.

These programs whitelist all the existing programs in your computer at setup and then for every new program that executes they ask you for permission to allow execution.

In other words you have control over the future program executions.


"Due diligence" in PCI requirement 12.8.3

12.8.3 is very ambiguously written, but what it boils down to is that you need to vet your potential service provider. You need to have procedural documentation showing the processes behind vetting a service provider. That part is pretty simple.

As far as what you should do to vet your potential service provider, that's a tough call. (and it's up to you to figure the majority of it out) Risk analysis will have to be done. Look into the reputation of the company and their past history. Ask tough questions related to what you are potentially working with the provider.


Should sensitive data ever be passed in the query string?

If the query string is the target of a user-clickable link (as opposed to a URL used from some Javascript), then it will appear in the URL bar of the browser when the corresponding page is loaded. It has the following issues:

The URL will be displayed. Shoulder surfers may see it and learn things from that (e.g. a password).
The user may bookmark it. This can be a feature; but it also means that the data gets written on the disk.
Similarly, the URL will make it to the "history" so it will be written to disk anyway; and it might be retrieved afterwards. For instance, if the browser is Chrome, then a lunch-time attacker just has to type Ctrl+H to open the "history tab" and obtain all the query strings.
If page is printed, the URL will be printed, including any sensitive information.
URLs including query strings are also frequently logged on the web server, and those logs may not be secured appropriately.
There are size limitations on the query string, which depend on the browser and the server (there is nothing really standard here, but expect trouble beyond about 4 kB).

Therefore, if the query string is a simple link target in an HTML page, then sensitive data should be transmitted as part of a POST form, not encoded in the URL itself. With programmatic downloads (the AJAX way), this is much less of an issue.


Can a website keylog you outside a virtual machine

TL,DR: Don't be worried, you are probably safe.
Usually malware cannot escape the VM onto the host OS. There are exceptions, as some malware are designed specifically to break from the VM into the host, but those are very, very few and usually are seen on targeted attacks, not on a public internet site.
Cross-OS malware infection are even rarer. Malware infecting your Ubuntu installation and jumping to Windows are plausible but mostly theoretical. A malware that escapes Firefox sandbox, infects the guest OS, escapes the VM, infects the host, discovers other OS installation and infects it too? No, I don't believe such thing would be available on a public facing site. It would be a weapon so powerful that nobody would admit to have it, even less go using it left and right.


Why browsers implement stricter policy for local files

Aren't files already on my disk more trustworthy than those loaded from remote sites?

No.

Expected local HTML use case for normal (ie non-developer) users is they've gone to a web page, wanted to view it offline, and used the browser's Save As functionality to make a local copy. This does not imply any level of trust between the user and the operator of the site hosting that page and should not, in general, give that operator access to read other files from the user's hard disc.

In days of old, IE used to grant greater permissions to HTML on the local filesystem. The upshot was a ton of security holes, in that any application that could be persuaded to save a file containing HTML to a predictable path could typically be exploited to execute attacker code.


I went on that website and this is what I saw:

They are using the Customer Chat Plugin from Facebook.

They don't know your name, they're just embedding an iframe to allow you to speak with their Facebook page's administrator(s).

Only Facebook knows who you are.


penetration testing: NBNS response on different network

since both responder.py and metasploit listen on your host machine for the broadcast nbns packets you need to fool them into thinking they are part of your own network. (assuming the responses are created as udp sockets, otherwise you will need to change that code too)

the way i would trick them is by using tcpdump with a nc on the remote machine and stream it directly into the interface using tcpreply.

you need to forward a port from the remote host back to you, this should be pretty easy using the metasploit port forward, you need to bind a local port to the localhost on the remote machine.
inside metasploit:

portfwd -l 1234 -p 1234 -r 127.0.0.1

afterwards you need to use ncat and tcpdump on the remote machine so that nbns traffic will be forwarded back to you (notice that the filter should remove the packets you will be injecting, otherwise you will have a loop):

tcpdump -i [interface number] -vv -s 0 port 137 and ether host ff:ff:ff:ff:ff:ff|ncat -l 127.0.0.1 1234

and then you need to inject it into your own interface, nc is used to stream from the ncat on the windows host and tcpreply is used to inject the packets:
    nc 127.0.0.1 1234|tcpreply -i lo -

and run your metasploit/responder.py on the lo interface.


CSRF testing of an api endpoint using GET requests

As you started to mention, CSRF is only really useful for actions that change state, so this is not truly an example of CSRF.

From OWASP:

  Cross-Site Request Forgery (CSRF) is an attack that forces an end user to execute unwanted actions on a web application in which they're currently authenticated. CSRF attacks specifically target state-changing requests, not theft of data, since the attacker has no way to see the response to the forged request.

Further, the reason you are not able to see the response is likely due to Cross-Origin Resource Sharing (CORS).

MDN web docs states:

  For security reasons, browsers restrict cross-origin HTTP requests
  initiated from within scripts. For example, XMLHttpRequest and the
  Fetch API follow the same-origin policy. This means that a web
  application using those APIs can only request HTTP resources from the
  same domain the application was loaded from unless CORS headers are
  used.

So while the remote resources are indeed fetchable, the browser is disallowing the JavaScript on your test pages from viewing the responses. Note that is the default behavior unless you have gone out of your way to set the correct headers on the server.


Can a PostScript .PS file contain a virus?

I believe that you did no want to ask if a Postscript file can contain a virus but if Postscript can be used as attack vector. There are actually several examples where the complexity and power of Postscript could be used for malicious purposes:

Hangul Word Processor and PostScript Abused Via Malicious Attachments. This used a vulnerability (CVE-2017-8291) in the embedded Ghostscript engine and allowed an attacker to cause code execution when the victim was reading an Office document. Note that the same bug in Ghostscript could also be used outside of HWP.
Microsoft Office CVE-2015-2545 Remote Code Execution Vulnerability.This is a similar issue, only for Microsoft Office. See also How the EPS File Exploit Works to Bypass EMET (CVE-2015-2545) – A Technical Exploration. And because this bug was used widely, the code had probably more bugs and the EPS functionality was not really needed anyway Microsoft finally disabled it: Support for EPS images has been turned off in Office.
Attacking the network using code execution in networked postscript capable printers: We don't want to alarm you, but PostScript makes your printer an attack vector.


Zap Proxy - script to modify headers automatically

Answered here: https://github.com/zaproxy/zaproxy/issues/4022

For simple replacement theres the Replacer add-on: https://github.com/zaproxy/zap-extensions/wiki/HelpAddonsReplacerReplacer and for more complicated situations there are httpsender scripts: https://github.com/zaproxy/community-scripts/tree/master/httpsender


IP address- is it dangerous for someone to know?

Actually it is not dangerous on some aspects, your IP address is your basic identity  to your system when connected to internet and if someone knows it then you can be exploited on some basis for some instant of time.
But it is difficult to establish a persistant connection because every time your pc restarts, it gets its new ip address.
So no need to be afraid.


In terms of academic conferences, the top conferences are:

IEEE Symposium on Security and Privacy
USENIX Security Symposium
ACM Conference on Computer and Communications Security (CCS)
Network & Distributed System Security Conference (NDSS)

For cryptography, there are other conferences (CRYPTO, EUROCRYPT, PKC, etc).

Microsoft Academic has a pretty good ranking based on citations and other metrics:

http://academic.research.microsoft.com/RankList?entitytype=3&domainID=2&last=0&start=1&end=100

(There are interesting changes to the ranking if you compare "All Years" to "Last 5 Years")


Different SSL states as seen by Safari, Chrome and Firefox

The screenshots show that the problem is not in the end-entity certificate (the actual server's certificate) but in the intermediate CA which issued it (the one just above): that CA is also shown with the "red cross". The error messages you see just tell you that the server's certificate cannot be used because its issuing CA is not trusted. To know why that issuing CA is not trusted, you have to click on it.

From my own systems, I see no problem with that issuing CA, and my browsers are happy with it (Firefox, Chromium on Linux; IE 8 on Windows XP). A possible reason may be a failure to obtain the CRL and/or OCSP information from the "DPWN Root", making it impossible for Safari to ascertain whether the "DPWN SSL CA" certificate was revoked or not (use of CRL and/or OCSP depends on the browser, the OS, and the configuration of both, so this may explain conflicting results).


No, NTFS is not encrypted by default.

  can data be read straight from the sectors in clear text?

Yes, by default NTFS files are unencrypted.  Since NTFS 3.0, EFS (Encrypting File System) is a feature of NTFS, but

  By default, no files are encrypted, but encryption can be enabled by users on a per-file, per-directory, or per-drive basis.


What you describe is not "attachements on images" but these are polyglot files, i.e. files which get interpreted differently by different programs. For example if you combine a jpeg (at start) with a ZIP file (at end) the image program will deal with the image while the archive program with the ZIP file since processing of ZIP archives is done from the end but processing of jpeg is done from the start.

I don't know of any exploits against games, image viewer or similar this way but this technique can be used to bypass analysis since many antivirus products expect the file to be of exactly one type. Thus the main danger for the end user is that a file containing malware might not be properly handled by the antivirus and the malware did not get detected. But, you should not rely fully on antivirus anyway.


How does gpg decryption command know which key in a key ring to use

The PGP format has a header that lists the key ID. You can read this detail in RFC 2440 section 5.1.

  The body of this packet consists of:

  A one-octet number giving the version number of the packet type.
     The currently defined value for packet version is 3. An
     implementation should accept, but not generate a version of 2,
     which is equivalent to V3 in all other respects.
  An eight-octet number that gives the key ID of the public key
     that the session key is encrypted to.

This header can contain multiple recipient key ids.


Is there a list of known deprecated/unsafe certificate authorities?

Since anyone could stand up a new CA that wouldn't be trusted, you may be better off just taking the union (or perhaps intersection) of the CAs trusted by the major browser vendors.

That said, you can probably get the information you asked for from a combination of the following sources:

https://aka.ms/rootupdates
https://blog.mozilla.org/security/category/ca-program/
https://www.chromium.org/Home/chromium-security/root-ca-policy
https://support.apple.com/en-us/HT207177
Custom search of Mozilla's bug database


SQL injection without the use of union and select

This filter searches for UNION, SELECT, union, and select. So UnIoN or SeLeCt will pass the filter.


Is checking a pre-shared fingerprint of a certificate good enough security for TLS?

What you are referring to is usually called pinning, i.e. check that the certificate or the public key in it are known to the application by either comparing the certificate/pubkey itself or using a fingerprint for validation.

This is a perfectly valid way to validate a certificate as long as the fingerprint is strong enough, i.e. SHA-256 is fine while MD5 is long considered broken and practical attacks against SHA-1 were just shown so it is bad too. But, having only pinning does not offer a way for the client to check for certificate revocation. This might be fine if the certificate check is done inside an application and the application will be quickly updated with a new fingerprint when needed but it is not a good idea if there is no way to update the expected fingerprint in a secure way.


How to know if two IP addresses point to the same web server?

You could compare the Last-Modified HTTP headers for some static resources (e.g images, css), from each IP, and see whether they are different. If they are different I would assume the IPs are separate hosts.

You could also make a request to both IPs at the exact same moment and compare the Date HTTP header in the responses - if they are different then the IPs are likely to be different machines with their clocks out of sync.

If the site uses session cookies, you could start a session on the first IP, and then try using the same session cookie with the second IP, and see whether it recognises your session. If it doesn't then you are probably on a different host, if it does then you might be on the same host, or the sessions are not getting managed in the web server.


Web of trust and signature types? (sig1, sig2, etc)

Jens has answered this quite well.  Basically, the signature levels are defined in the man page under --ask-cert-level and --default-cert-level.  sig refers to cert level 0, which "means you make no particular claims as to how carefully you verified the key."  This is the default when signing a key.  They run up through levels 1 and 2, to the highest level, sig 3, which "means you did extensive verification of the key."


CSRF-protection using authentication token in HTTP header?

Short answer: yes, it would be secure if correctly implemented (long enough, random, unique tokens, one per session, etc).

Long answer: If you decide to add a custom header to the requests sent to the server using JavaScript code, it is similar to sending an anti-CSRF value in the POST parameters (the more often used approach).

POST /test
Host: www.example.com
X-AuthToken: unique_random_value

p1=val1&p2=val2

or

POST /test
Host: www.example.com

p1=val1&p2=val2&x-authtoken=unique_random_value

So it's up to you to decide which option is easier to implement, but both should work in a secure manner.


What is the purpose of using hex escape sequences when writing buffer overflow exploits?

A hex escape sequence \x{whatever} represents a single byte of data. That byte can represent different things depending on the program reading it. For instance, \x78 could represent the character "x", the number 120, 'the 120th byte of the following section', or any special meaning assigned to it in context. If you write the string of characters "0x24840408", it'll be interpreted as the string of bytes \x30\x78\x32\x34\x38\x34\x30\x34\x30\x38 (you may notice that the characters "0" to "9" are represented by \x30 to \x39). When you write character strings here, they're simply interpreted as the corresponding string of bytes, the computer doesn't look at what characters those bytes represent. When your debugger prints out the address "0x8048424", it's not printing what's actually stored in memory - it's trying to be helpful by interpreting the four byte sequence \x24\x84\x04\x08 that's actually there and printing a string of characters humans can understand (Also it can't print \x24\x84\x04\x08 as the characters it represents because three of those characters are either unprintable or invisible).

It would be possible for a program to convert the other way and turn "0x24840408" (or indeed "0x8048424") into \x84\x24\x04\x08 in memory, but the python interpreter doesn't do that by default because it's not often needed outside of exploit development. If you really do mean 'put this four-byte value into memory verbatim', that's what escape sequences are for.

So, to summarise:
"0x24840408" is represented in memory by \x30\x78\x32\x34\x38\x34\x30\x34\x30\x38
\x24\x84\x04\x08 represents "$[three unprintable characters]"* (ie. \x24 represents $ - but we don't care what string it represents because we're interpreting it as an address)

*actually it'd usually be "$[one unprintable character]". \x08 as a character represents 'backspace', so it should remove the \x04 before it. But that's not really the point.


Why encrypt password fields? Answering management

Passwords should be hashed (not encrypted - encryption implies that it can be reversed) for two reasons.

The first is that users are negligent and keep using the same passwords for different systems. No, they should not do this, but many people do it nevertheless. So when your password database gets compromised, people can not just log into your user's accounts on your system but also to accounts in any other system where they use the same username&password combination.

Now the suits will ask about the business impact of that risk. After all, it doesn't affect their profits if users get hacked on some completely different service owned by a completely different company. The only argument you can provide here is the Public Relations argument one.

The second problem are internal attackers. When employees can see the passwords of any users they don't like, they can log into their accounts, impersonate them and wreak all kinds of havoc with them.

Now the suits could argue that a rogue employee has even more effective ways to harm users and that they will be fired if they try. But they forget that employees also have a private life. When they log into user accounts from outside the company (and sufficiently cover their tracks), there is no way to find out who it was. Or even find out that it was an employee and not someone who obtained the password from hacking some cleartext password database of a different company.


Responsible Disclosures and Getting Sued

Welcome to the conundrum of the security business and why it is more profitable to be a bad guy than a good.

Remember this about "getting sued"... Anyone can sue anyone - even if there is nothing justified to sue over. If an entity has money to sue the entity that doesn't have money to fight it looses, almost automatically. 50% of the time or more, if you get sued for some of these things, you are also having to fight off state or federal (or your country's equivalent) criminal or regulatory authorities at the same time.

This is why insecurity will always reign, and why I am sure no one wants any of it fixed.

Here in the US, if you even inadvertently find an issue and report it to a product owner you could be facing their civil (sue) wrath, you could be facing DMCA and others. What do I mean by inadvertently? I could be debugging what I think is an issue with my local machine acting wonky and decompile, or source code from a 3rd party (where I find the problem). Now remember, they are causing the problem to MY machine and I am trying to figure it out... As soon as I find it, and report it, I could be in this grey area.

And I am not even "hacking" per se.

So the rules have been written badly and poorly to really allow for public disclosure. I think that is why organizations that want bugs and security concerns to be found have create very open and clear "bug bounty" programs and do so with a very "open kimono" approach.

What I have seen work in absence of those, is to do what a lot of researchers do... set up anonymous accounts that you can report the information to the organizations to, and don't take credit for it until well after it has been taken care of - I guess that is unless you are hacking Facebook. Seems like everyone is in Facebook's face hacking it aggressively and publicly :).


How to protect external hard drive from tampering?

To protect against physical removal and later unauthorized access, just encrypt it completely using one of the available software like VeraCrypt (container-based or full encryption). In such a scenario getting it will make it not accessible anywhere.

On the software part, you will have to secure from unauthorized access the OS used to access the drive. If you have encrypted the drive and you must enter a password for it upon restarting the OS and you secure the OS against possible unlock scenarios you should be fine.


Which is more secure: saving reference link to file in file system in the database, or save the entire file into the database?

The difference is not too big from a security perspective. If your database is breached, the attacker will either have the actual data or working access to it. If the files were to be properly stored externally, in the case of an attack as a direct quick response you could deny access to them (by means like dismounting the location they are stored on) but this is a special case.

From a data perspective, keeping a lot of large files in databases is not good and not recommended. Databases were not designed for file storage.

So my vote goes to links in DB and separate files.


Is it easy to evade a ban if you have a Dynamic IP?

Yes, in general a "block" will beaten with a new IP if it's an IP block. I'd suggest VPN as you can't control your ISP and their are different ways that they do IP reservations and NAT. It is possible to block on useragent and some other things also, but in general I see IP bans used the most. IP bans are a flawed way to stop an attacker. When we ban IP's we run the risk of shutting down connectivity for multiple users who share that IP. Why is this still used? There isn't much else when you have a really malicious attacker. Good SOC's and IR are aware of these issues and usually bans have a shelf life: 30 days being one I'm familiar with personally.

Turning your router off and on might, but probably won't change your IP. You will most likely have a "lease" and that will change depending upon it's time limit. Internet cafe's will have IP's based on their ISP and plan, most of which seem to be a standard enterprise plan without anything fancy like a reserved IP range or etc. On the note of if the new IP will be close to the last one, yes most likely. IP's cost money to "own" so typically buy a sequential range so you'll get assigned randomly to another in the range, very close to the last one.

I'd suggest asking the geolocation question separately from this post as it is a very different topic.


Security Architecture - Settings to drive UI and Privileges (Rights) - Role-Based, per User-Account

I think it highly depends on end use.  Just off the top of my head and without knowing a ton about your app end user, have you thought about session based authentication?  Basically do a check on their permissions and apply some type of identifier to their session.  That way you could grant requests allowable permissions, which should be faster than checking all user permissions on every request.  Just have a lookup table for an action and what sessions are allowed to use it, that way you could store everything centrally which is a lot easier to manage.  Just a side note, this is purely a response on ease of implementation/manageability/speed, the more secure you want your app to be obviously the more you are going to sacrifice speed.  What will really drive your implementation is figuring out the reasonable balance point between acceptable speed and security.

I'll post a more lengthy response when I have some more time later on today.


Secure keyboard entry with JavaScript or Flash?

No, since that would imply that Flash or JavaScript does have access to raw hardware, outside of its sandbox.

Think opposite, that if a flash applet or JavaScript applet would have this access, it would be possible to build a keylogging website that remained Active across tabs.

If you need to protect against keyloggers, I would suggest some sort of 2FA. Then it wont matter if the password does fall in the wrong hands, as long as the token does not fall in the wrong hands.


Working code examples for stack or heap buffer overflows?

Exploit-DB is a well-known repository for exploit code and includes a number of overflows.  For example, here's one against socat which includes the steps required to exercise the overflow.  Some exploits have more information, some less, but if you browse enough you should find the sort of shared exploit you're looking for.


How to manually disable the no contact card?

You will seriously decrease your security by disabling the radio or chip in your credit card.

Chip and PIN is the most secure form of payment available today, followed closely by Chip and Signature; contactless payment is almost as secure; mag stripes are completely not secure, and hand-keyed account numbers (such as on a web page) are the least secure of all.

It may help to understand the different protocols in use.  The data provided by the chip, either through electrical contacts or via the Near Field Communications (NFC) radio, follows a different payment protocol (called EMV) than the data provided by the magnetic stripe.

First, be aware that all cards, including chip, mag stripe, and contactless cards transmit data in the clear*.  The data includes card number (also called the Primary Account Number, or PAN), expiration date, and some kind of verification value.  The bank uses the PAN to look up the account, checks the expiration date, then validates the appropriate verification value.  If they match, the bank goes on to approval processing.  If they don't match, the bank declines the transaction.

Believe it or not, the account number isn't the problem.  The problem is when all of this data is copied together, including the verification value.

There are two different Cardholder Verification Values on a mag-stripe credit card.  There is the Cardholder Verification Value (CVV), which is embedded in the mag stripe's data, and the CVV2, which is the 3 or 4 digit number printed on the back of the card, and is for use in "Card Not Present" transactions (such as paying online.)

When a card is mag-stripe read, the entire track of data from the mag stripe is sent to the bank.  The bank looks at the track data and will require the CVV from the track to match their records exactly.  If a card is hand-keyed (as on a web site), the bank requires the CVV2 from the back of the card to match.  Stealing the mag stripe does not get the thief the CVV2 so he can't buy online; stealing the CVV2 from a web site does not enable a thief to recreate a mag stripe and create a counterfeit card.

However, the basic problem with the mag stripe is that all the data is static.  Because the track data can't be changed, the CVV is static. Because a credit card is printed, the CVV2 never changes either.  That means if the card data is read just once by a thief, it can be copied and replayed again and again, resulting in fraud.

That's where the contactless cards are different.  Because they have an on-board chip with a CPU and memory, they generate a single-use transaction-specific verification value.  With each subsequent transaction, they generate a different verification value.  The bank uses cryptography to validate the verification value was correctly generated on each transaction; this confirms that it was their chip that was present, and not just a copy of the number.  This means that copying all of the authorization data, including the PAN, expiration date, and verification value, does not give the thief enough information to replay the information and commit fraud with the data.  Similar protocols protect Chip-and-PIN and Chip-and-Signature transactions.

Instead of clipping the NFC antenna, you are much more secure if you use only the contactless radio for payment.  However, since many shops don't take contactless payments yet, you still need to use your mag stripe at those locations, where your data is still vulnerable and subject to skimming.  And when you use your card online and type in your CVV2, it's also potentially vulnerable to theft.

If you want to increase your security, let the merchants where you shop know that you're unhappy that they don't take contactless forms of payment, or if they don't yet take chip cards.  The more they hear from their customers, the more likely they are to upgrade their equipment to a more secure device.

If you're extremely paranoid, you can certainly buy a cheap RF-blocking envelope to keep your card in your wallet from being skimmed by the guy next to you on the bus; but even if he does read it, the data he reads can't be used to create a working clone of your card.   (At most, a very sophisticated attacker could have an accomplice paying for a diamond ring at the exact time the guy on the bus reads your card, channeling stolen payment data through him as a proxy.  And that's why you should tell your bank you would rather have Chip and PIN than Chip and Signature.)

EDIT For clarity, here’s how I rank the various payment schemes in terms of security, from best to worst:

Chip and PIN
Chip and Signature
Mobile payment systems(Apple, Samsung)
NFC (contactless with dynamic authentication data)

...

Mag stripe
Web entry with two-factor authentication
Web entry

* Some contactless technologies, such as Apple Pay, use a substitute number in place of the PAN.  While this sounds more secure than the cleartext account number found on chip cards, this means your banking information is always present inside Apple's systems, where you have to trust they won't be hacked, and that your iPhone and iWatch won't be hacked.


VPS host shows plain text "root" account password upon reinstall of unmanaged VM

If somebody wants to access your virtual server via SSH, they need the server's IP address and your password. However, if there is no password in place, they could immediately set a password and misuse your server. You assume that you will log in earlier than an attacker.
However, if your VPS provider already set a password, then the attacker also needs to guess it. There shouldn't be a problem if you change your root password.


Can wifi router be ddosed by "trying" to login to router repeatedly and in very fast manner?

I think the closest type of attack to what you're referencing would be a WiFi deauth attack. There are ways to protect against it, but ultimately I think trying to secure WiFi against dos is like trying to secure a glass door against break-ins by putting more locks on it. WiFi operates on unlicensed spectrum, so no license is required to transmit. The tradeoff you have to accept when you use unlicensed spectrum is that everyone else can transmit on it too, so there are no guarantees on the quality of that spectrum. You can put in all the technical defenses you want but it will have a hard time stopping someone who just comes along and spews noise on the spectrum.

  -- btw, i know that a jammer could always be used in such a distance, but i am avoiding worrying about high skill attacks, since they are
  illegal, and an amateur would have a hard time trying to produce one.

Laws will of course vary depending on jurisdiction, but making WiFi unusable through a deauth attack could also be considered a form of jamming and potentially also illegal, so I'm not convinced that someone willing to perform a deauth attack would be unwilling to perform RF jamming. Additionally, a lot of WiFi interference happens unintentionally. Microwave ovens are infamous for wreaking havoc on 2.4Ghz spectrum. Cordless phones, wireless security cameras, baby monitors, and neighboring WiFi networks can all cause interference, sometimes to the point of making WiFi unusable. These forms of interference would generally not be considered illegal jamming, since it's unintentional.

Another interesting tidbit about how WiFi works is that as a form of congestion control, if a WiFi device hears another WiFi device transmitting on the same channel, it must wait for the other device to stop before it can transmit - even if the other device is associated with a completely different network. So even the existence of another network on the same channel as yours, if transmitting data constantly, can severely degrade the performance of your network.

In conclusion, if guaranteed network availability is important to you, wired connections are the way to go. WiFi should be for convenience only.


The stack used is Rails 4.2.4 + Postgresql 9.3 + Puma + Nginx 1.4.6.
The server I'm running is Ubuntu 14.04.2 LTS on an AWS EC2 t2.micro
instance.

Ruby on Rails 4.2.4 is vulnerable to a directory traversal attack when the render method is used (since Puma runs on RoR, this could potentially an issue). While this does not give an attacker access on its own, it can be escalated into a remote code execution attack. Upgrade RoR to version >= 5.0.0.beta1.1 to protect against this.

Postgresql 9.3.x is vulnerable to several attacks, ranging from DoS to the more serious buffer overflow attack. Upgrade PostgreSQL to the latest version to protect against the various vulnerabilities in the version you are using.

Nginx 1.4.6 - I don't actually see a record of version 1.4.6. Regardless, there are at least two known vulnerabilities that affect versions 1.4.x. Upgrade to the latest version to protect against these vulnerabilities. (Actually, the latest vulnerability was announced last month, and the newest mainline version [1.9.9] is still vulnerable. It is a DoS attack, and can be prevented with targeted firewall rules)

I access my server by ssh using a private key...

Unless you have edited the sshd config to allow password login as well, this is sufficient in ensuring a remote attacker cannot bruteforce your SSH login. If the computer you use as an SSH client is ever compromised however, you should consider the keys compromised as well.

How did hackers compromise my EC2 instance?

Difficult to say without more information. A list of running services, firewall rules, and a stack of log files would help.

My issue is that I want to make sure this never happens again...

Tough cookies. As long as you have a publicly facing web server, it will get attacked. The better approach to take is accepting that this can happen again in the future, and prepare for it. Some realistic things you can do are keep software fully patched, tune your firewall rules (do you really need to give access to the whole world?), implement an IDS/IPS on the AWS local network and route all traffic through it, and finally log all traffic and forward to a hardened logging server.
This is perhaps the most important step in understanding how you were hacked, and how to prevent it in the future. Grepping through log files is an option, but having a clean visual representation of your server's logs makes it much easier to detect anomalies, and to later search when a server is attacked. Having a separate, hardened log server is important because if your web server is compromised, the attacker can erase traces of the attack locally.
If you wanted to go one step further, you can automate the process of detecting anomalies, and define reactions based on that.


Logging someone else's google account on my Andoid device

Google products will not try to merge two separate accounts even if it is signed in on the same device. The only way to transfer data between two accounts is via exporting from one account and importing to the other.


Is cascading cryptographic algorithm better than using a single one?

scrypt(bcrypt(password)) will be less secure when considering the attack model scrypt is geared against - namely requiring as expensive hardware as possible for brute force attacks.

However, if you believe that the scrypt construction or the primitives used in scrypt (SHA256, Salsa20) are prone to failure, using bcrypt as well brings in another cryptographic primitive (blowfish). However, it might just as well be that there is absolutely no benefit.

In general, I would strongly advise against combining methods like this without actually understanding the ramifications and proving that some meaningful benefit is gained.

Edit: Oh, in case you didn't know, scrypt uses PBKDF2 both before and after its own method, which is probably the most widely used method for strong password hashing - certainly much more used than bcrypt.

Edit: Probably the closest cryptographic papers on the issue are those evaluating the combination of SHA1 and MD5 in the TLS PRF construction, such as: Hash Function Combiners in TLS and SSL.


What characters that are converted when running PHP on IIS?

Can anyone explain...?

Perhaps the developers at Microsoft can explain why they chose to apply globbing in this context. Personally I find it really silly - but sadly not the first time I've seen such counter-intuitive behaviour on Microsoft's platforms.

Note that the quote comes from a section on the owasp page on how NOT to do file uploads. The author is here explaining how to exploit the vulnerability. By default, browsers will use double quotes to delimit - indeed, I believe that the spec inherits from RFC 822 which requires double quotes - so in the absence of an escaping mechanism, you cannot embed double quotes within double quotes. Again, you would need to ask Microsoft why they chose to forge their own path.


Secure Routing without relying on Cryptography?

In general, no ad hoc network is actually secure unless it is encrypted because whatever method you would use to validate into it would be transmitted in a readable, and therefore, reproducible way.  For example, if the protocol said you have to send me your MAC or IP address so I can make sure you are on the white list, then an attacker could sniff packets to find what identifying factors are being sent, then just pretend to be that guy.  If you use a username and password, then that will also be transmitted, unencrypted, and be able to be reused.


Does a OS manufacturer have permission to access your computer unauthorized?

Legal

No. Unless you explicitly permitted it.

I suspect if such permission was embedded amongst many other clauses in a EULA, it could possibly be nullified by a court of law if the clause was deemed unconscionable. But if there is no precedent for this, someone would have to risk the time and money for a test case in the applicable jurisdiction. You could ask the Electronic Frontier Foundation if they have explored the topic.

Technical

Unless your computer is always on and acts as a public server, organisations do not access your computer directly - but rather the organisation's software "phones home" like an evil ET.

You can control with an outgoing firewall which applications are allowed to phone home, but certain applications and operating system components tend to malfunction without outgoing internet access. So if for example, you want desirable updates and bug-fixes, you need to accept the risk of the company including undesirable features or behaviour. There is a profound degree of trust required of end-users by software companies.

Precautions against third-party software doing something undesirable are much the same precautions as you would take against a  malicious Trojan. Indeed, all third-party software which can self-modify and access the internet can be considered a potential time-delayed Trojan.

Some Precautions (incomplete list):

Limit applications to installation, execution and file permissions of a sandbox. Services on a Unix system are often restricted in this fashion (e.g. apached)
Separate the operating system, user applications and data into three or more different partitions. If the operating system is stable and doesn't required further legitimate updates, periodically flush the operating system partition with a protected ghost image.
Have multiple backups with different retention time-frames, to limit the likelihood of a Trojan contaminating of all of them before igniting its warhead.
Have your important data within an encrypted container, mapped to an unusual drive letter.
Examine running processes in a proper diagnostic tool (vanilla task managers are inadequate). The tool can show you what background services the application has installed, what ports are being listened on, what files have been opened, etc.
Explore what exactly the application installed or updated, if an installation log is available.
Prefer open source software.

The take home message is that companies will often do what they can get away with, especially in regards to advertising and your personal information. You have to be proactive with each application and each update; but this level of pro-activity is very tiresome so eventually most people just accept the risk.

If you truly don't trust companies modifying your computer, start getting very familiar with pure GNU-style Linux distros and source code compilation...

As DKNUCKLE's reference to NSAKEY suggests, spy agencies have little or no need to break encryption like a Cold War spy novel. Breaching any of the hundreds of applications you need to use in order to function in the 21st century is quite sufficient.


How to proceed with a white-hat hacker claiming a vulnerability?

To answer each of your questions:

1. Basically how to proceed or even should we?

I recommend proceeding. You will be able to acquire valuable information that can immediately be put towards improving the security of your company. You haven't told us what the researcher has sent you, but they will either have a description of the vulnerability or methods to reproduce it. To proceed you will need from them:

A description/attack scenario of the vulnerability found. Why is this an issue, what specifically does the bug allow an attacker to do that they shouldn't be able to do, what is the worst case scenario/severity of the finding.
Reproduction steps. What steps could you give any engineer and allow them to reproduce the bug every time.
What the hacker is looking for in return. As mentioned it may be permission to publish the finding after fixing or money.
You might also want or receive remediation advice, risk scores, etc. from the researcher.

VERY IMPORTANT: make it clear to the researcher that you expect them to keep the issue confidential until the issue is fixed. They may counter with a remediation window, e.g. they get to publish and article if the issue is not fixed within 60 days. This is common practice and should be acceptable to most companies with a strong security posture.

2. What is the common expectation from a white (hat) hacker?

Depends on the researcher, but they will likely want permission to publish the finding once it's been fixed as well as a monetary reward. Reward prices are based on overall severity and size of the bounty program. Hackerone, a large bug bounty platform, has a matrix that suggests payouts relative to size of the company/bounty program: https://www.hackerone.com/resources/bug-bounty-basics. Determining payout price is a subtle art - I recommend searching hackerone or other bug bounty platforms for similar bugs and basing your payout on what other companies are paying for the same issue.

Again - a common expectation researchers will have is that they get to publish the finding in a certain amount of time regardless of whether it's been fixed by then. 60 days is common, but I wouldn't agree to an amount of time if you're not confident your company can deliver in that window. After the issue is patched, the hacker may want to validate that the fix was implemented correctly.

3. How to validate?

Use the reproduction steps the hacker has given you. They should be clear enough that any engineer can follow the steps exactly and reproduce the bug. If there are any issues here you can go back to the researcher and get clarification. It is the researchers responsibility to supply the company with reproduction steps that outline and identify the bug.

Once the issue is fixed you can invite the researcher to validate the fix and ensure that it was patched completely.


What is the most robust available algo for GPG symmetric encryption?

Use AES-256 (because it stops people from lecturing you about quantum computers).
If you don't have particular (performance) requirements in mind, 256-bit AES is a good and safe choice. But that doesn't mean there are practical attacks against the other ciphers. Ultimately, it's a matter of personal preference since nobody can predict which theoretical observations might work as  practical attacks in the future.
In fact, you can also safely use AES-128, which is about 30% faster. There is a bit of a disagreement whether it's worth switching from AES-128 to AES-256: Doubling the key size doesn't prevent any current attacks because searching the key space is not practical either way. However, the difference becomes  important when at some point in the future quantum computers might be able to execute Grover's algorithm which effectively halves the key size and hence could make brute-force attacks against AES-128 feasible. But that's a theoretical future scenario. The article "Guess why we're moving to 256-bit AES keys" is a good read on AES key sizes.
Similar to @SteffenUllrich I'm comfortable with the AES family because due to its status as a NIST standard, AES has been studied extensively and it has been around for quite a while without anyone having published any concerning weaknesses.
The GnuPG FAQ has an opinion, too:

11.10 What are the best algorithms in GnuPG?
MD5 and SHA-1 should be avoided if possible, and for bulk encryption it’s best to use Camellia, Twofish, or AES. Beyond that guidance there is no “best algorithm” in GnuPG. It’s sort of like asking whether Godzilla or King Kong is better at terrorizing urban cities: there is no clear-cut winner.
This is not to say you shouldn’t have preferences, though. It is only to say that GnuPG’s algorithms are so well-designed for what they do that there is no single “best”. There’s just a lot of personal, subjective choice.


How can Linux service installation page create an attack surface?

"that's a way" requires an antecedent, and it is very vague.

The page being up? No, that doesn't offer a way in. It's static.

The information on the page? If the info helps someone to craft a way in, sure, but then the information isn't the way in, it's merely a resource.

I think this is simply a case of someone not being careful when speaking.


Why is it not possible to fake a digital certificate?

A digital certificate, especially the most-common X.509 format used for TLS, has a number of parts. Three of the most important are the subject name, the subject public key, and the issuer signature. The first two tell you who the certificate is for (such as "*.stackexchange.com"), and what the public key that corresponds to that entity's private key is. Spoofing these parts would let you use a certificate that was issued to you for intercepting requests to another server (by changing the subject name), or using your own public/private key pair to decrypt the key exchange and thus decrypt the entire TLS connection (by replacing the subject public key with your own public key). Therefore, the certificate needs to be protected against tampering, and the recipient of the certificate needs to be able to tell whether the certificate was spoofed or not (you could, after all, just make up the subject fields). That's where the signature comes in.

Digital signatures are created using a private key, not a public key, so only the holder of that private key can create the signature. Anybody who has the public key can verify the signature, though. Typically you create a signature of a short byte string, called a cryptographic hash digest (the output of a function like SHA-256), because public/private-key cryptography is slow (though you could, in theory, sign the entire certificate). Verifying the signature string turns it back into the original digest. If the verified signature does not match the digest of the certificate (which the client can compute themselves), then the certificate is not trusted (because it's been tampered with or has a fake signature).

Because the only entity with a CA's private key is (in theory) the CA itself, only the CA can create signatures that will verify using the CA's public key. The client doesn't need to ask the CA whether it signed the certificate; if the CA didn't sign the certificate, then the certificate wouldn't have the CA's signature on it (unless somebody else got ahold of the CA's private key, which is the kind of failure that tends to put a CA out of business). An attacker also can't just take the signature from some valid certificate X and put it on a fraudulent certificate Y, because when that signature is verified it will match the digest (hash function output) of certificate X, but not the digest of the fraudulent certificate Y (unless the attacker has found a collision in the hash function, which is why nobody trusts certificates signed with old and broken hash functions like MD5 anymore).

Clients, such as your browser, know what the CA's public key is because trusted CA certificates (which include public keys) are included with your client, or even with your operating system. Therefore, I can't just sign something with my own private key and pretend Verisign signed it; Verisgn's public key is already known to your client and wouldn't verify the signature, so you wouldn't trust the certificate. This trust is often used transitively; a root CA (like Verisign) might say "I trust this so-called intermediate CA, so I'm going to sign their certificate (including the part that says that their certificate can sign other certificates), and you should trust them as you trust me." The intermediate CA can then sign a certificate for a web site or something, which is at the bottom of a "chain of trust" that connects the web server's certificate to the root CA certificate by way of the intermediate CA.


How does varying character type increase strength of password?

Your assumption is that attacker password guesses are uniformly distributed among the domain of potential passwords. This assumption is incorrect: guesses are skewed toward more likely passwords, which are lower-case dictionary words as those are easiest for users to type and to remember.

The benefit of using a complex password then is that it will probably take a longer time for the attacker to try your password as a guess. Incidentally, when considering a large multi-user system, the "no need to outrun the lion" rules apply and in many cases a good password is one that's more complex than another user's. That is not always true if an attacker is specifically targeting you rather than the system.


network traffic decryption with proxy devices

The CA will not provide you with a certificate for a proxy. They will also not provide you with a certificate for a specific server. They will just provide you with a certificate matching a specific hostname (or multiple names). Where you use this certificate is up to you (some CA might restrict this). You might even use the same certificate on multiple system.

This means for your case that you could use the same certificate both on the proxy and on the final server, i.e. terminating the TLS traffic at the proxy and then having another TLS connection with the same certificate to the real server. But you could also terminate the TLS traffic at the proxy with the certificate issued by the public CA and then use a different certificate for the real server by using your own PKI which is trusted by your proxy. Or, if the connection to the real server from the proxy is considered protected by other means (like IPSec) you could also use plain traffic without TLS to connect from the proxy to the real server.

By terminating the TLS connection in the proxy the proxy has access to the plain text and can also make changes to the traffic, like requesting authentication, filtering traffic in a WAF etc.


How does the DANE protocol make Certificate Authorities obsolete?

DANE makes it possible for every owner of a domain to publish its certificate inside the DNS, i.e. fully managed by the owner of the domain which is the owner of the certificate. But, DANE needs DNSSec because otherwise such records could be spoofed which would a major problem with certificates. Thus while DANE does not rely on a certificate hierarchy to build a chain to a trusted root CA it still relies on a similar concept: a key hierarchy with trusted root keys.

The main difference to CA issued certificates is that the domain owner can fully create all certificates belonging to its domain itself and insert it into this hierarchy of trusted keys. Similar revocation is easier since the key has simply to be removed from the DNS. This of course requires that the domain owner is able to manage its own DNS records and that these are protected with DNSSec.


What are the security features of the proposed "secure email" from Brazil?

No one knows at this very moment. (thanks @Terry)

It is highly possible that it is not even defined. There are several options, depending on what the Brazil government wants to do: do they want to stop spying, or do they want to stop spying from NSA ? (In the latter case, this means that Brazil could want to maintain possibility of spying by themselves).

The linked article contains the following excerpt:

  Data will be stored on local servers.

and also that one:

  For the user of the future service to actually be protected, however, the message recipient will also have to use Correios' email.

Both hint at some sort of network of decentralized encryption gateways. End users would connect to a specific gateway which would do all encryption and decryption, and ensure protection against spies on the big network links. However, the gateways would be in ideal place to spy on users. In a business context, we may imagine that each corporation would run its own gateway.

NSA spies would have to fall back to the methods that they.. already use... e.g. keyloggers or even simple bribery. Let it be a message: ye shall pay your sysadmins well, because they can see everything if they are such inclined.


How to appropriately secure a database using different db users

Separating by Tables

Separating by tables seems like a good idea, especially if you can estimate the importance of tables to your security. For example a table with usernames and passwords is pretty important, while a table with blog comments is less important. If you have a different database user for those important tables, an injection into eg a query that selects comments might not gain an attacker any real advantage as they cannot access relevant data (the most they could do is reflected XSS).

Separating the blog and website also looks reasonable (at least from a system design point of view), but I would give each of them a separate database (they don't really seem to belong to each other, so it makes logical sense, and would also be easier to handle).

Separating by Read/Write

I'm not sure that separating by write and read would be worth it (what would be the actual thread it defends against? I think mainly an attacker injecting a blog post), and it will probably be hard to enforce. For example if you have an admin user which can edit the database via a web interface:

attacker can read: attacker can read out admin password, and thus write (via web interface)
attacker can write: attacker can add admin password, and thus read (via web interface)

Managing the privileges by table prefix also does not seem like a good idea. Consider this (this might be a bit far-fetched, but it's just one example of how to bypass your rules):

website_read has select rights on website_*
global_write has write rights on website_* and blog_*
blog_read has select rights on blog_*
attacker has access to global_write and blog_read (eg via injection) and wants to read out website_users (to which they don't have the rights)
attacker renames table website_users to blog_users with global_write [*], and reads it out with blog_read.

[*] If this is actually allowed would depend on your concrete system, but generally rename is a write activity. Eg MySQL requires ALTER, DROP, CREATE, and INSERT which I would call write rights.


Can anyone tell me what's going on with two sets of strange web site visitors?

Probably just some crawlers, bots, nothing to worry about it. Just make sure that your website is secure and there is no data leaking.

From my experience I saw that many website owners are just careless about their data, so it is easy to find sensitive data on their website.

Especially take a good look if some of these kind of files are publicly available:

*.sql, *.log, *.bak, *.old etc.

Just run:

find . -type f -name "*.sql"

Than check on Google:

site:yourwebsite.com ext:sql

Use Google Alerts, it will alert you if any of your sensitive data appear in Google searches.


Does a public key stay the same when a certificate is renewed?

I've typically done so by creating a renewal CSR and giving it to the CA. When the CA gives me a new (renewed) certificate and I install it, will it have the same public key as the old certificate?

The CA copies the public key from the CSR to the Certificate. When you create the CSR it is up to you what key you put in it. You can choose to use the same key as last time, you can chooose to use a freshly generated key, you can choose to use a key you just pulled out of your cold storage vault, it's all up to you.

  Currently we get around the issue by pinning to the intermediate certificate that signed the leaf certificate (longer shelf life).

This is a bad idea. There is no gaurantee that future cerfificates will be issued from the same intermediate cert.

  So I'm implementing certificate pinning

I strongly suggest the following.

Only pin the end entity key, don't try to pin the whole chain. You have no idea whether future certificates will be issued by the same root and intermediate keys.
Make sure you have spare keys that will be recognised by your client, having your application recognise only a single key leaves you up shit creek without a paddle if that key is compromised. Your spare keys should be kept in cold storage and ideally should include a selection of types/strengths in case you need to move to stronger keys in the future.


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

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


Does a virus need to be clicked on to function?

A virus can't do anything by simply being present on your system as data.  A virus is just a program, it must be executed by something.  The trick is that that something does not have to be you clicking it.

Computers do many things automatically without your attention.  They accept requests for file transfers, remote desktop, provide details about their state, check for system updates, etc.  Additionally, you perform many actions that can be hijacked by nefarious code on another system, such as running websites with Javascript or Flash or running programs that pull data from the Internet or process documents (such as e-mail or office documents).

Any of these hundreds of paths of execution can be used to either trick a system in to running a virus that is downloaded with a website or to even remotely cause execution of a virus loaded on to the system without any user interaction at all.  So while you could (generally) safely download a copy of most viruses and let the code sit dormant on your system, there are a great many ways that an attacker could potentially cause a virus to be installed on your system without you taking any direct action.  (This is, in fact, the way that the quarantine option normally works in a virus scanner.  It just renames it and copies it to a different location.)

That said, I'd still recommend setting up a virtualized environment to test with.  There isn't any good reason not to, they are easy to setup and provide an extra layer of protection.  There is a very slim possibility it might be able to abuse some system process, such as hooking a search indexer or thumbnail viewer.  However, there is also a very slim chance that a virus may be able to escape a virtualized environment.  The odds of it doing both become increasingly unlikely though, especially if you change the extension on it to disassociate it from many system processes that might otherwise process it differently.

This is why it is so important to use things like firewalls on your network and to keep your operating system and other applications patched and up to date.  Security patches are released to fix holes as they are discovered, but many undiscovered or unpublished vulnerabilities certainly still exist.  Things are secure enough that not just anyone can break in to your system if you keep it up to date, and as long as you keep attackers off your network with a firewall you are probably pretty safe though, especially if you disable active content (like Flash and certain Javascript) when browsing the Internet.

As XP no longer gets security updates, you are left high and dry against any newly discovered vulnerabilities and it will become increasingly easy for a remote code execution vulnerability to be used against your system without there being anything you can do to stop it short of removing your computer from the Internet.


Can contacts be stolen over public WiFi?

When you're on public Wi-Fi, anything your smartphone transmits unencrypted, including contacts, can be intercepted and read by anyone within radio range.
The question is, then, does your smartphone transmit contacts? Many apps do, but they will mostly use an HTTPS connection to their backend which encrypts the information.
So I think you'll be safe if you stick to well-known apps. The only way to be sure, however, is to use a tool like Wireshark to inspect the traffic your phone sends over the network.


Are there any exploitable protocol flaws in WPA Enterprise?

Shouldn't there be a certificate warning on the phone?

There should be a warning but this depends on the client side implementation.

For example in europe there is a academia wide wireless network called eduroam which is available at almost every university. Eduroam is utilizing WPA2 Enterprise and email + password as credentials.
Some month ago the local universitys IT department announced that eduroam should not be used from smartphones because some of them don't do the certificate validation properly/at all which makes them vulnerable to attacks like the one you referenced.


Potential FileVault problems in my setup

What law enforcement can do, depends, yes, on the state of your computer, and on how many good computer scientists they know and how politely they ask for help.  Please keep in mind that encryption can be broken using brute-force methods, and there are some really powerful computers out there that can break weak encryption schemes.  Of course law enforcement getting access to those powerful computers and the computational expertise required to break the encryption is quite a feat of political savvy.  Such a method would probably involve computer science research, so I will answer the question with methods that already exist in the public domain (i.e., methods that are readily accessible to law enforcement).

While the laptop is in sleep

A determined person could try an exploit that attempts to use lan-scanning events to gain access to the OS.  Most of these successful exploits use the wireless card.  Some of these exploits yield significant access, and sometimes root access, depending on the operating system.  These exploits do work on Mac OS X.

Since you have the ability to reset your password using the AppleID, a politically savvy professional could convince Apple to give up your AppleID or enter it to gain access to the OS.

There are USB trojans that yield root access on Mac OS.  A determined professional could use one of these trojans to gain access to your data.

There may be iPhone/iTunes vulnerabilities which can be used to gain access.
While the laptop is locked, but the user logged in

Remember that they encryption key for the hard-drive is on your computer, somewhere that it can be access very early in the boot process.  This key should be accessible by rebooting the machine in a different OS that can read the boot portion of the hard disk.  It is possible that with some OS-specific expertise, the key can be located, and subjected to a brute-force password hack.  Such a effort would very likely be successful, and it would only require a small cluster of computers to do this quickly.
While the laptop is powered off

If the computer can be booted, then this offers very little more protection over the other states.  Did you set a bios password or boot password?  If so, then the determined professional would have to brute-force those passwords.  Then they could employ any of the techniques listed above.

On the other hand, the easiest thing that law enforcement can do is deprive you access to your data forever.  With this encryption scheme it is very easy to destroy the contents of the hard disk by destroying the encryption key.  I assumed above that your main concern was someone accessing your data.

Please keep in mind that the techniques mentioned here have a lifetime.  These things work until the vulnerabilities are repaired.  These methods are current as of late last year, 2015.


ABAC policy formulation and RBAC question

Axiomatics provides an authorization policy lifecycle that will help you formulate your ABAC policy.

Define the use case
Define the use case’s authorization requirements in natural language statements
Identify the attributes that are used in the natural language statements
Identify where the attributes comes from
Rework the natural language statements as attribute-based rules
Define the test cases
Connect the dots: draw an architecture diagram of the overall system

Let's work through your example.

Use Case

One online book-store wants to grand access to clients regarding their subscription. There are 3 types of subscriptions A , B and C.

Authorization requirements

Customers get access in the subscription type they choose.
If a book is not listed in the subscription list it's free for all.
Every 15th of every month all books are free.

Identify attributes

User Attributes

User role e.g. customer
User subscription plan e.g. A, B, C
Optionally customer status (active, inactive)

Resource Attributes

Book subscription plan

Action Attributes

Action id e.g. view, delete, approve...

Contextual Attributes

Date / Day of the month

Identify the source of the attributes

In this stage you define whether the attributes come from a database, an LDAP, a web service... This is more of an implementation / deployment concern. In this theoretical exercise, you can skip this step.

Rework the natural language statements as attribute-based

A user with the role == customer can do the action == download on an object of type == book if customer.subscription == book.subscription
A user with the role == customer can do the action == download on an object of type == book if book.subscription == ''
A user with the role == customer can do the action == download on an object of type == book if date.day == '15'

In conclusion it means your RBAC model needs a single role, customer.

You can use the ALFA language to model your policies and convert them into XACML, the eXtensible Access Control Markup Language.


MITMF Is not connecting Metasploit (HTTP Injection)

If you are using Kali Linux, resolve this by using the following command to install MITMf

apt-get install mitmf

Even if the original instructions provided by the software author work as expected with no errors, they are still tragically awful.


Is Bitlocker secure enough for portable storage devices?

A cold boot attack is impossible on an offline device. The only way an attacker could use a cold boot attack on your portable storage device is if they also had physical access to your computer as it was plugged in the disk unlocked.

A cold boot attack relies on encryption keys being stored in RAM, and the persistence of that RAM once the computer is hard reset.

In short, you shouldn't worry too much unless there's a nation state after your data. Even then, I'd trust BitLocker unless there's a backdoor.


Is a honeypot an IDS or an IPS or something else? Is it an offensive or a defensive technique? Is it still effective?

Typically a honeynet is used as a defensive tool and is used to (sort of) trap attackers. It is designed to fool them into thinking they are on a real system (though most good attackers can quickly detect it's a honeypot). By fooling the attacker, the "honeypot owner" is hoping to learn more about the attacker's motives and techniques. The honeypot is designed to be compromised but should not be placed anywhere in the infrastructure such that it can be used a staging or pivot point for further compromising of the "real" environment.

A lot of folk talk about "Defence in Depth" quite a bit and the honeypot is another facet of that and is designed to complement the other layers. Like attackers evolving, honeypots have evolved and changed also (the usual "arms race").

Technically speaking, a honeypot can be used as an offensive tool (for educational purposes) whereby a person wants to learn how to attack and exploit box, however, as I previously said it's more commonly used as defensive mechanism.

Regarding its viability or relevance today, there has been much discussion and there've definitely been issues with honeypot techniques and deployments but I still believe that honeypots are relevant, a great source of information and if used correctly, can enhance the security of your environment.

I don't like giving Wikipedia links but this one does define honeypots pretty well.

I also recommend reading about the Honeynet Project, it's absolutely awesome - they do fantastic challenges, give back amazingly to the community, participate in the Google Summer of Code and have some awesome technical papers.


Implementing key vault and key rotation for a non-cloud application

The question is making incorrect assumptions on some of the details.  For example, it says to calculate a password hash, and it looks like it is assuming the hash is used as the cryptographic key to encrypt/decrypt the key on the key server.  But that's not normally how key servers operate.

Key servers have their own encryption mechanism and will encrypt all their keys with their own key (usually called something like the "master key" or "Key Encrypting Key (KEK)".)  When you connect to the key server with a password, the server will authenticate your username/password combination.  You will then request access to a specific key name or key identity, and if you're authorized it will grant your access.  Depending on the server's configuration and your request, it may export the key to you so you can use it to encrypt and decrypt, or it may provide encryption/decryption services to you.

The key server's job is to securely store the keys, and to perform key lifecycle management functions (key generation, key destruction, etc.)  A key server may provide key rotation functionality; but because there are no cryptographic standards for key rotation or key versioning, the implementations will be server dependent.


Is crimeware defined by anything other than intent?

First things first, you are slightly misusing the term Virus and since you said you wanted to learn I mine as well teach a little extra.

If you imagine types of malicious software as a tree, the very top of the tree (root node) is malware. Basically its the words malicious software gelled into one word. A virus is a form of malware that is defined by the way it re-produces. Viruses are defined as a virus because they can transfer themselves from host to victim in almost anyway including over a USB stick, email, internet, program download etc. and is a very generic term.

  I read the wikipedia page for crimeware, and to me it seems that crimeware is just a specific usage of spyware.

You are correct, what defines crimeware is exclusively the intention the attacker has for creating their malware. For example, a Trojan horse could be crimeware. The Trojan is the delivery mechanism (Hey look at this super cool flashlight app! Wow, so cool. Why does it need Internet permissions and file permissions? Ah don't worry about it.) but the real reason for creating this flashlight app you can only download off a third party website is because it is a Trojan horse delivery mechanism for some crimeware key logger. The flashlight app may contain a key logger that transmits back to a command server it's findings including all the passwords you type in.

This of course would be different than a Trojan horse flashlight app who's end goal it is to encrypt your entire phone's drive and demand ransom (Ransomware).

Crimeware is just a spin-off of Spyware and I imagine (although I have not first hand analyzed examples for comparison) that Spyware and Crimeware are near identical in how they are written, but may be delivered and behave slightly differently as they have different goals. For example, Spyware includes things such as watching people on their webcams whether that be for corporate espionage or for perverted reasons, you choose, both exist.

  Is there anything a network administrator needs to know specifically to defend against Crimeware that isn't included in plain-old spyware?

I would say no, not really. Crimeware is just a more tailored, targeted type of Spyware and the same sort of precautions should protect you. Keep un-needed ports closed, do not download un-trusted files, be careful with phishing emails, avoid putting potentially infected USB's in company computers and keep personal devices off the network.


Will blacklisting a stolen iPhone prevent the thiefs from getting access to my data?

No. If they have the device, and there is no encryption enabled (e.g. lock screen PIN), they can read whatever they like from it. They won't be able to use it as a phone (they could use it as a fancy iPod if they wanted) in countries which support phone blacklists, or to access Apple services, but any data stored on the device itself could be accessed. This may include any data stored in Apple provided services, if the password for these was stored on the phone, and not been changed since the theft.


Can a custom built CPU break hard drive encryption?

There isn't any comparison operation with the passphrase, because there's nothing to compare it against. The plain-text passphrase isn't stored in the system anywhere (if it was, an attacker could steal it without guessing, brute-forcing, or needing some legit user to enter it). The exact operations done depend on the disk encryption software (Bitlocker, FileVault, VeraCrypt, LUKS, etc. all work a bit differently) and what mode it's operating in (sometimes, there's no passphrase at all; the key comes from a file on a flashdrive and/or a hardware security module called a Trusted Platform Module or TPM) but generally, the passphrase is run through some form of password hashing / key derivation algorithm, which is a non-reversible cryptographic operation that turns a passphrase into a binary string suitable for use as a cryptographic key. Even the output of that function (the digest) isn't going to be compared against anything directly either - after all, if the attacker gets that, then it's just skipping the passphrase -> hashing step, so you can't store the digest anywhere either - but you can hash it again, or use it to decrypt some secret and check the integrity of the decryption, and in either case (hashed key's digest, or authentication tag for decryption), that is data that can be safely stored on the disk because there's no way to get any actual secrets back out of it.
With that said, of course a maliciously modified CPU could steal the passphrase as it's entered. Every keystroke on the keyboard will, after various operations that might take place off-CPU (e.g. in a microcontroller inside the keyboard or on the motherboard's USB controller), end up entering the CPU (computer firmware - the BIOS or UEFI - have at least a basic keyboard driver in them, and it runs on the CPU even if the OS isn't running yet). You're not going to be capturing it during any comparisons - because none are performed on the passphrase - but it's still there for capture (briefly).
Mind you, there's lots of other places you could capture such data. A classic example is a hardware keylogger, either inside the keyboard itself or between the keyboard and the motherboard. Another option is in the USB host controller on the motherboard. Another is in the RAM, since that's where keyboard input is buffered until the CPU processes it (and also, mostly inevitable, any time the user types a string such as a passphrase it ends up, at least briefly, resident as a string in RAM). Finally, there's the keyboard driver in the firmware / pre-boot code.
CPUs are the most complex components of most computers (high-end GPUs may have more transistors, but may well still be a simpler design writ large), and only a few companies are capable of manufacturing high-end x86 CPUs, so it's a relatively unlikely place for a malicious implant. Not out of the question, but you'd need a ton of resources, and by the time it's even viable to replace somebody's CPU with a malicious one, there are easier attacks by far.

Also, this isn't really breaking hard drive encryption. This is just stealing the passphrase needed to get the decryption key. That defeats the encryption, but it doesn't break it, any more than somebody finding the "secret" key under your door mat and using it to unlock your front door is "breaking" your lock. Actually breaking the encryption - for any modern cryptographic cipher, implemented even half-decently - requires expert cryptanalysts to study the cipher for a way to even proceed (other than dumb brute-force) and even then, the best known attacks against any modern ciphers are well outside the potential of any one CPU even if you let it run for decades. Quantum computers might change this, for some ciphers, but they're still far from practical for use on real-world problems of even the size "encrypted hard disk and you don't have the key".


It's perfectly possible to use the Synchroniser Token pattern together with proper navigational/multi-tab support. It's only if you take the questionable advice:

  To further enhance the security of this proposed design, consider randomizing the CSRF token parameter name and or value for each request

that you have problems. In reality there is no good reason to do this on every request.

There is only a benefit to cycling the CSRF token at the point where a session elevates authorisation - typically on login and other paths that changes logged-in state (eg registration, account recovery, switch-user). These are the points at which you should also be cycling your session identifier, so it makes sense to do both at once. Changing the session ID prevents session hijacking through session fixation; changing the CSRF token prevents a CSRF attack through session fixation.

Navigation back to a cached page in the logged-out or previous-login state (or holding one open in another tab) and then trying to do something will indeed break, but most people probably won't be expecting that to work at that point.

You can put in some JavaScript to detect that situation if you like, checking that the session cookie matches the one that was used at page creation time. (Or an associated cookie that isn't the identifier and isn't httponly, as appropriate.) Then if it doesn't match you can add a warning div and reload link to the page, and/or prevent active form controls on the page from being responsive. You'd run that check onload, plus onpageview for bfcache if you're allowing caching, and potentially on an occasional poller to catch the multi-tab case. (This can also be of use to catch session timeout on the client side and present a friendlier error.)


How paranoid are you?
Level 1:
Use WinRAR or 7-Zip to create encrypted archives and share them over any file-sharing mechanisms. SHare the password over completely different means of communication.
Level 100:
Use encryption software (Like VeraCrypt) to create an encrypted volume with a key and passphrase. Share the key separately (maybe an encrypted archive) and passphrase separately.
Level 9999:
Ask your client to create a PGP key for himself and share the public key with you. You also create a PGP key with for yourself and share the public key with him. Now sign your file with your key and encrypt the file with your client's public key. Share the encrypted and signed file.
The sign can be validated by the recipient so he's sure the file is sent by you and only the recipient can decrypt the file ensuring your data is read only by your recipient.


So let's say you navigate to www.example.com/page?main.html and it puts you on the main page of example.com. Now you navigate to the index, which is located at www.example.com/page?index.html. You start to wonder, what other pages are there?

So you type in www.example.com/page?foo and hit enter, and you get an error page which will say something like "Resource foo is not found".

The thing to note here is that you put a parameter into the URL, and that parameter got reflected back to you as the user. In this case, it was the parameter "foo".

Now the idea behind reflected XSS should be a bit more clear; instead of inputting a lame parameter like "foo", you input something like <script>alert(1)</script>foo and hit enter. On a vulnerable site, that entire parameter will get injected into the error page that pops up, the javascript will execute, and you'll get a popup in addition to the "Resource foo is not found" message. If you can induce somebody else navigate to the same link that you crafted, you can execute arbitrary javascript in their session.


Why aren't we scared of our signing key being stolen with JWTs?

You ask actually multiple question within a single post:

Risks connected with unauthorized access to private key
You are mixing different processes: message/authorization signing (in JWT) and securing communication channel (SSL)
Trust to encryption strength

To signing and private keys: Of course there are risks. There is whole industry around this, with standards, practices etc. It is impossible to name everything related to it. How to mitigate risks? Again, too broad question. Just some random hints: limit physical access of persons to hardware, "need-to-know" principle, access control and regular reviews, identity management, audits, layered security, short living certificates for JWT signing keys , e.g. 1 month, and their CA chain long living.

To encryption strength (quote: I hope they won't break the encryption): Of course, except one time pad there is no perfect encryption. I'd suggest you to ask about reliability at another site, Cryptography SE, not here. The guys will explain you why one can rely on AES, RSA, ECC and what are conditions for this (particular modes of operation, role of randomness), what are the risks.


Preventing XSS by filtering data from the server to the client

The answer is at the point where you're generating HTML, is where HTML encoding/sanitizing should occur.

If server side code is generating the HTML then it should be server side. If client side is generating HTML then it should be client side.

In other words if server side is generating JSON to send to the client then server should be JSON encoding the data, but not prematurely HTML encode.


What are the appropriate steps to take after installing a questionable Android app?

Having a rooted device and running an outdated ROM both greatly increase the odds of a malicious app gaining root privileges without user authorization.

How did the user manage to get root?
That's just one method that the malicious app could use to get root.

With root one thing that the malicious app can do is install another app that won't show up in your list of installed apps. You deleted the first app, but not the second, so you aren't actually any better off now.

A factory reset might not get rid of your problem, but correctly flashing a new ROM should.


What are read state and write state in SSL connections?

It's the state of the encryption.  The pending state includes new encryption keys, and initialization vectors.  There is a write key for sending data, and a read key for receiving data.  The state of the keys and resulting IVs are the read and write states.

So when the current read/write state is overwritten with the pending read/write state it means that the new encryption keys and IVs are to be used for future communication.  Until a new Change Cipher Spec message is received.

The significance of these states is that they keep track of the cryptographic state as data is being encrypted and decrypted.  When a new key is negotiated these states are updated to use the new key that was negotiated between the peers.  Key renegotiation is common among most cryptographic protocols.

To follow up on the comment by @Makif, the cryptographic state is complex.  It keeps track of:

Symmetric algorithm (mode of operation and size)
Asymmetric algorithm
Symmetric encryption keys
Initialization vectors
Integrity keys (Message Authentication)

Essentially everything in a cipher suite, and any (or all) can be renegotiated and changed when a Change Cipher Spec message is received.


What attack requests "wp-admin" URLs without login cookies?

Without knowing the complete requested URL (and any post or get vars) it is impossible to say for sure.

There are numerous things they could be trying. It could as Gray suggests someone carrying scans to ascertain which domains are running wordpress (however getting this information from Google would be a much easier prospect).

Another possibility is that someone has misidentified your domain as running wordpress (has it ever used wordpress?). They could be scanning your site using something like wpscan. If wpscan is being used I would expect many other requests around the same time looking for other files (for example the plugins folder).

As you suggest they could also be looking for a specific vulnerability. However without knowing what scripts they are trying to reach and if there are any post or get vars then it wouldn't be possible for us to ascertain this.


How to safeguard physical keys stored in a fire dept. lockbox?

To be clear: a Knox Box is a lock box that holds keys for emergency personnel. If the fire department needs to get inside your building while it is locked, the fire crew will have a key to unlock your Knox Box and retrieve your building's key.

There are a couple of ways to mitigate this risk. The easiest IMO is security cameras that watch your doors. If someone unlocks the Knox Box and uses your key, the camera will pick them up and you can respond appropriately.

What I often see either to automate this or in conjunction with this is, the Knox Box is hooked up to an alarm system. When it's unlocked, the alarm goes off alerting your security company that someone has obtained access to the key. If it's a true emergency and responders are on scene, this will not have any impact. If it's not an emergency and it's a burglar, the police will now be notified to respond.

Most Knox Boxes I've seen have a hookup to wire them into a security system. Here is a link to a fire department recommending this approach.


Is authorisation of FTP safe against sniffing and vulnerable to man-in-the-middle hijacking?

The authorization with FTP is plain text username and password and there is no protection against passive sniffing.

FTPS (FTP over TLS, not to be mixed up with SFTP which is file transfer over SSH) offers protection against sniffing. But many FTP clients don't check the TLS certificate properly or let the user easily skip the check and thus can be vulnerable against active sniffing (man in the middle attack).

Classical session hijacking as known from HTTP is not a problem here because there is no such kind of session. It is still possible to hijack the underlying TCP connection. But this needs an active man in the middle and works only with plain FTP in which case using passive sniffing to get the password would be the much simpler attack.


SFTP on Windows - is it likely to be disabled?

Because SFTP runs over the same protocol as SSH, there is no valid technical reason to refuse to enable SFTP.

That said, there may be company policies that prevent this. There is a big difference between an SSH connection to issue commands, and an SFTP to transfer files. A company might accept the risk of allowing an approved account to access another machine, but might balk at the transfer of data.

So, technically, the risk is the same. Functionally, there is a big difference and an organization might have a policy against it.

This is the case in an area of my organization. We allow SSH to some servers, but no data transfer to/from those servers and have monitoring to ensure that the traffic flow stays below a certain threshold. Granted, it's a special case, but there's precedent.


xmlns.jcp.org domain SSL cert weirdly invalid?

I see the same error if I connect to https://xmlns.jcp.org/, so if it is an attack, it's not targeted at you or your local network.

Interestingly, https://jcp.org/ is serving a different certificate and I don't get any errors on that one. That one has only the following SubjectAlternativeNames:

DNS Name=jcp.org
DNS Name=www.jcp.org
DNS Name=www2.jcp.org

I spot-checked a number of the domains in the list you provide, and they all either redirect to an oracle.com URL, or include the Oracle logo somewhere on the page, so my guess that they use that mega cert for websites of random small companies that Oracle has acquired. I'm guessing they used this cert on https://xmlns.jcp.org but forgot to check that it's actually covered by that cert.

My conclusion: Oracle being sloppy with their sites, redirects and certificates.


I found that the company I work for is putting a backdoor into mobile phones

Just because they won't use it, doesn't mean someone else won't find it and use it.

A backdoor is a built-in vulnerability and can be used by anyone. You should explain that doing something like this is very risky for your company. What happens when some malicious attacker finds this backdoor and uses it? This will cost your company a lot of time and money to fix. And what will your company say when people ask why the software contained that backdoor in the first place? The company's reputation might be damaged forever.

The risk is certainly not worth having it in the code.


Is there any actual security benefit to restricting foreign IP addresses?

The concept is "reducing the threat surface". If there is an expectation that no connections will be made from a certain geographic area, then it makes sense to block that area, because, by definition, it is not legitimate. In theory. (For a health provider, it's a weird choice since customers might want to manage their health while traveling, but this is a side issue.)

For one company I worked for, there was a list of countries that listed the Top 12 worst offenders for cybercrime, and we did not have any customers in those countries. So, it made sense to block them.

Could attackers use proxies/VPNs to attack from an allowed IP? You bet.
Did they? Who knows.
Did we experience high volumes of attacks from those 12 counties anyway? Oh yes.

We saw an immediate 80% drop in traffic to our webservers when we started the geo-IP ban.


Is using X-Real-IP as a way to check for localhost access safe?

You are already asuming that only localhost traffic can reach your web app on port 5000. Thus, checking any header you set in nginx is not the factor in deciding wether this is a request from localhost - all are, by definition.

If your question rather is

  can I assume that all that have the 'X-Real-IP' Header set come from 'nginx'"

the answer would be "no"; you can easily curl that on localhost.

Edit to reflect the edit in the question:

You can assume - with your presumptions - that every request on port 5000 comes from localhost, regardless of the headers.

As of now (i.e., to my knowledge, there is no exploit to allow that happening regardless of the configuration), if that configuration is all the configuration there is, there is no way to make nginx forward a request without setting the header.


Can plain text be hidden/accessed in laptop Firmware? (or elsewhere, not HDD/SSD)

The very simple answer is yes, and you can check this for yourself by reading BIOS information, or the text that is stored in various devices and drivers. You could even store text in the firmware in most modern keyboards.

Next time you update your BIOS, look at the upgrade file in a hex editor - loads of text in there, comments fields etc.