Password manager: safer on laptop or on smartphone?

I don't understand why you don't want a password manager that works on both? Your non-tech friends that don't use a password manager yet are too limited by your requirements. You seem to be running in paranoid mode. Your friends want something that is convenient.

If you can get them to move to Lastpass, that will be a huge improvement over their current security.

It can be shared on phone and laptop for free now.
It has 2FA, which is probably already much too complicated for many, and very inconvenient, but it does have this option. If setup properly, it prevents logins from unknown computers.
Lastpass has its own 2FA app, making it even easier.
If someone logs in from another location, you get an email about it.
Login can be limited to certain countries.

NB: I don't mean to limit this to Lastpass. Other password managers like 1Password probably have the same bonus. I don't use them, so don't know. Keepass is an offline option, but sharing the database in Dropbox or Google Drive makes it kind of online, but still more difficult to use.

Some questions:

What is your objection to Lastpass or similar solutions? I don't say that you have to use it. It's for your friends, who need to step up their security to use something instead of nothing. Lastpass is a lot more secure than nothing, in my opinion.
Why you don't mention the password managers you consider? It would make this discussion a lot more meaningful!
What is it with choosing between laptop and phone? So I can't use passwords on the phone that I use on the laptop? If your friends log on to Facebook, they need them on both the phone and laptop!
Non-techies can type at incredible speeds! Further down your question you talk about passwords that consist of normal words. Most people can type normal words at normal speeds.

I'm afraid that your solution will turn out to be dumped on the first occasion where inconvenience turns its ugly head. Be wise and choose the compromise!


How do attackers determine ROP gadgets remotely?

ROP gadgets are based on the process' executable pages, which in practice usually means based on the process binary and the binaries of any libraries linked to it at runtime (there are exceptions with processes that use JIT compilers, like browsers, but mostly that's not the relevant situation). This does mean that building a ROP chain requires knowing the process being targeted pretty precisely, including which architecture it's compiled for.
So, how to do that? Well, for a lot of things, it's pretty easy: most software doesn't change very often, so you get target the current version, and there aren't that many architectures in use so you can usually target x86 (if Windows desktop), AMD64 (if Linux or MacOS desktop, if one of the programs where the default Windows version is AMD64 now, or any server), or ARM/ARM64 if targeting a specific mobile device. Most malware isn't trying to target a specific computer, it's just trying to spread as wide as possible, because the impetus behind most malware is money (ransomware and cryptominers, but also old-school spyware and even adware).
So, you just target the most common kind of system that runs the software you have an exploit for, and the most common version of that software (at least among vulnerable ones). Remember that ROP is a payload; if the correctness of your ROP chain matters at all, you already exploited the process and gained control of the instruction pointer! Typically, that means you know pretty precisely the relevant software version.
Some info gathering is also an option, especially for more targeted attacks. Software such as nmap will try to guess operating system identity and software version based on either explicit version strings or heuristics about behavior. Some software just outright tells you all the relevant details, such as browser user-agent strings. You can also look for data through other sources, like if you're targeting a company, have they published anything about their infrastructure?
Another option is a multi-payload target. You build a collection of payloads, and then you hide them behind a bootstrapper that extracts some information about the system after initial exploitation, and loads the appropriate payload. This is, practically speaking, often mandatory anyhow: ASLR is near-universal now, and it breaks most situations where you would use ROP unless you can extract some object from memory and compare it to what you expected in order to determine the ASLR mask. Since you then must apply that mask to your ROP chain (unless you found a library without ASLR to target), you're already sending a custom ROP chain anyhow.
Finally, you can just try 'em all! If you're attacking a server, odds are that it's on a cluster of machines all running identical hardware and software. So you exploit one (whichever the load balancer gives you first), and if that doesn't work you just try again. The first server will probably crash if the initial exploit succeeds at all, but that's OK; the load balancer will probably stop targeting it until the watchdog brings it online again. This kind of brute-force approach is very "noisy", of course - tons of servers crashing unexpectedly tends to set off alarms - but firing off network requests is fast and most exploits are even faster, so you might still be able to get in before any human response can be mustered. What you do then is hard to say - the defenders will be trying to kick you out ASAP - but it's totally possible to try something like grabbing some secrets (keys, credentials, private files, whatever) or just doing quick recon for a future attack once they stop watching so closely.


How do Field Programmable Gate Arrays (FPGAs) compare to Graphics Processing Units (GPUs); for cracking hashes?

What exactly is an FPGA?
An FPGA is not like a GPU. A GPU is a pre-designed processor with all the circuitry already there. All you have to do is hook it up and let software interface with it. FPGAs, on the other hand, are completely different beasts. They are a "blank slate" processor. You have to design an FPGA, not just buy one. You determine what transistors do what, how they hook up, etc. They are efficient because every part has a job, but they require you have a deep understanding of electronics and integrated circuit design.
In the question you linked explaining what makes a GPU so good at password cracking, it says that a GPU has a large number of identical cores that can run the same algorithm in parallel. How the core works internally is something that you don't need to know in order to make use of it (and likely can't legally know). For an FPGA, however, there is no such unit. You create each core and design it. You set up the individual logic gates. Basically, you design the chip, using the FPGA as nothing more than the actual, physical hardware that contains the transistors. Developing on them can be difficult.
Which is faster for hash cracking?
For the same price, a high-end GPU is likely to be faster than an FPGA at processing hashes, but an FPGA is likely to use less power for processing the same number of hashes. It's important to note that there are several different kinds of FPGA. An FPGA "conversion" involves creating an ASIC from FPGA HDL. This is often quite expensive and is only done when purchasing in quantity, but tends to be a bit faster than a regular FPGA (apparently around 30% faster), and much easier, and cheaper, than designing an ASIC. A true ASIC is, of course, much more efficient than either. Designing an ASIC is even more difficult than programming an FPGA, and requires far more knowledge of low-level integrated circuit design. Overall, ASICs are efficient and fast, but costly and hard to design.
Which should you get?
If you want the highest possible MHash/s for a given price, or if you need the flexibility of supporting multiple algorithms, get a GPU. If you want the highest possible MHash/J (joule, an energy unit), get an FPGA. If you want both speed and efficiency and do not care about price, design an ASIC.
If you are new to password cracking and just want to build an efficient cracking rig, get a few fast GPUs. FPGAs and ASICs are typically used if you are a company with a team of developers with a large (but strict) budget to work with, when custom solutions are needed. For most password cracking needs, a GPU would do just fine, not only because of their competitive speed, but because popular hash-cracking software like Hashcat is designed to make use of GPUs for acceleration. Nothing of that sort exists for FPGAs or ASICs, meaning you'd have to design it all yourself.
An excellent post on the Electronics Stack Exchange explains the difference between FPGAs, ASICs, and general-purpose microcontrollers (which a GPU is most similar to) in more detail, from an electronics design perspective, rather than a hash-cracking perspective.


Would this RESTful login system be secure?

No, you're actively harming usability with no gain to security.

This sounds like a bad case of Security Theater*!

I say this because what you're currently doing is only just as secure as sending over the username and password over HTTPS anyways! All you add is a couple of extra setup communications. The vulnerabilities of this implementation as well as the vulnerabilities of HTTPS sending of password and username are exactly the same.

Let's break down the example:

Setting up and using the secret

Establish secure connection
Send payload to be stored
Confirm payload, and if confirmed log in

Setting up and using a password

Establish secure connection
Send payload to be stored
Confirm payload, and if confirmed log in

These steps are exactly the same, and provide no extra security. If a full takeover(MITM/system level) happens, the same thing that would happen with a username and password will happen to your system. The attacker will still see all data as it is transferred and accessed between your system and the server. This is why full takeovers are so dangerous. There's basically nothing you can do to protect the user. The user is using a system of communication that is no longer theirs, but the attackers and that attacker can see, and use everything in the communication.

Really all you're doing is generating a secret(commonly called a password) to be stored, and some meta data(commonly called a username) to identify it. If the meta data and secret match an entry, you retrieve that information. The only advantage you're gaining is that the user gets an extra long password. But to what end? Bcrypt has a maximum character length, so you're limiting the number of characters the individual password can have. You now also have that shared secret to worry over getting the same every time or your user or they can never log in.

Passwords and usernames over HTTPS have been used so much so often because after a certain point(the HTTPS connection) there is nothing you can do to increase security. If someone gets access to all communications, or to memory space all of your techniques have just been defeated since they just have to recreate your steps and you may never even know until they carry out their attack.

*: As of last week this phrase is now macroed on my keyboard...
*: Security theater is the act of putting practices into place that do nothing to improve security, and may actually harm it!


Safely changing text links to HTML anchors

If you're only trying to convert links, the safest option is to use sanitization and a whitelist.  Basically a list of allowed values, which prevents anything you don't specify from being passed.  Always use a reputable sanitization function and whitelist, I would not recommend building your own unless you know what you're doing.  See a page like the following for reference (make sure all sanitization/validation is happening on the server side, of course):

http://jsoup.org/cookbook/cleaning-html/whitelist-sanitizer

I think the prospect of making your users use a markup language is a good suggestion for tag injected XSS, but it doesn't really address the issue of URI concat'd XSS.

I find the previous answerer's response of essentially saying that you should only prepare for simple attacks because otherwise you're "going down the rabbit hole" is reckless and naive, why don't we just put a simple lock on bank vaults in that case?


Why is finding a strong collision only half the work of a weak collision?

To find a collision, the attacker generates a large number of unique messages and their corresponding hashes.  The attack succeeds when any two hashes match.  This is just like the birthday paradox, which speaks of the probability of any two people having the same birth date.

  it only takes half the work

Careful, 2^128 isn't half of 2^256.  2^128 is the square root of 2^256.  2^128 is one "2^128th" of 2^256.

  the attacker has 2 messages 'place 10$ in my account' and 'place $1000 in my account' and they want them to hash to the same value [...] the attacker would continually keep changing both message until they hash to the same value

In this situation, the attacker is given m1 and m2, and wants to find an x1 and x2 such that H(m1 + x1) = H(m2 + x2).  Let's suppose that H is a 256-bit hash function, like SHA-256.  The attacker tries 2^128 different values for x1, computing and storing 2^128 hashes H(m1 + x1).  The attacker now tries different values for x2, computing hashes H(m2 + x2), looking for one that matches one of the x1 hashes.  Eventually, this will succeed, but after how many attempts?

There are 2^256 possible hash values, so the probability of each attempt succeeding is 2^128/2^256 = 1/2^128.  Therefore, we can expect this step to require about 2^128 attempts.  Adding the two steps together, this attack would require, on average, about 2^128 + 2^128 = 2^129 evaluations of the hash function.

I don't think this usually goes by the name "birthday attack", since the probability math is quite different.  Both attacks do have a similar complexity, however (about a square root of the search space, or 2^(n/2) for an n-bit hash function).


What CSRF attacks will 'First-Party-Only' cookies protect against?

In addition to your own answer, CSRF defences are still recommended and are useful:

"SameSite" cookies offer a robust defense against CSRF attack when
deployed in strict mode, and when supported by the client.  It is,
however, prudent to ensure that this designation is not the extent of
a site's defense against CSRF, as same-site navigations and
submissions can certainly be executed in conjunction with other
attack vectors such as cross-site scripting.
Developers are strongly encouraged to deploy the usual server-side
defenses (CSRF tokens, ensuring that "safe" HTTP methods are
idempotent, etc) to mitigate the risk more fully.
Additionally, client-side techniques such as those described in
[app-isolation] may also prove effective against CSRF, and are
certainly worth exploring in combination with "SameSite" cookies.

Although I do disagree with the XSS attack vector from the same Origin, as XSS always trumps a CSRF vulnerability - if an attacker can inject HTML and script they can circumvent most defences (or all defences with a bit of "social engineering" to trick the user into entering passwords or CAPTCHAs when required).
However, as jub0bs poins out, subdomains with vulnerabilities may be an additional attack vector.


Basic question regarding OpenSSL and AES-GCM

OpenSSL implements almost a dozen symmetric ciphers, and several dozen cipher-mode combinations, but provides a (nearly) single interface to all of them in the EVP module (i.e. external function and type names beginning EVP_) documented here online or in the (crosslinked) man page for EVP_{Cipher,Encrypt,Decrypt}* and EVP_CIPHER_* and EVP_CIPHER_CTX_* on any Unixy system with OpenSSL installed. (If you built/installed it yourself rather than using the package manager or equivalent for your OS or distro, you may need to use MANPATH or other man options to find the man pages.) Similarly numerous digest/hash algorithms and public-key (and hybrid) encryption and signature algorithms are accessed through generic interfaces; see man evp. But the AEAD modes (GCM and CCM, plus OCB planned in 1.1.0) do not exactly fit the generic API and require additional 'control' calls, see the sections 'GCM and OCB modes' and 'CCM mode' in the above man page.

The SSL-and-TLS module (top-level directory ssl/ in the source) contains code in t1_enc.c that does different EVP calls for (implemented) AEAD suites, in the same way it also handles variations for CBC and stream ciphers, obsolete but still coded 'export' ciphers, TLS1.1 vs earlier IV handling, and other protocol options and variations.

But commandline enc in apps/enc.c only uses the generic interface and not the AEAD specials, although there is an unassigned entry in the request tracker (login guest/guest) to add this. The commandline utilities in general are fairly minimal wrappers around functionality in libssl and libcrypto, and if you want something complete, polished, convenient, etc. the idea is you should either modify or replace them.
For this case you (would) need to define how the tag, and possibly AAD, is handled in the ciphertext file format, which is currently simple to the point of being trivial -- and remember any change that doesn't work with the probably millions of enc files users have stored over the past two decades won't be accepted by anyone but you. (update) The bugtracker moved to https://github.com/openssl/openssl/issues/471 where it is 'resolved' in 1.1.1 -- by documenting that enc does not and will not support AEAD. Also note that the early 1.0.1 releases, through patch g (2012-03 to 2014-04) failed to give an error message for this case; you could run the enc command with a GCM or CCM cipher, but it discarded the tag on encryption and gave an error on decryption.

Remember also that enc with a password (not actual key and IV using -K uppercase and -iv) uses a very poor PBKDF, a variant of PBKDF1 see EVP_BytesToKey with only one iteration.
See
openssl: recover key and IV by passphrase
and openssl enc uses md5 to hash the password and the salt
and https://crypto.stackexchange.com/a/35614/12642 (disclosure: mine).
Worrying about using best-practice ciphers like AES256-GCM with this PBKDF is like the proverbial gilding a cow turd.

The usage message for openssl enc -invalid lists all symmetric ciphers/modes in EVP, even those enc doesn't support. If you care, you could report this as a bug. openssl list-cipher-algorithms (planned space instead of first hyphen in 1.1.0) does the same, but openssl list-cipher-commands (ditto) lists only those usable as commands, which excludes the AEAD ones. (updates) In 1.1.0+ all command parsing is rewritten and the usage messages are replaced by -help which for enc does not list ciphers; the explicit commands are now list -cipher-{algorithms,commands} i.e. space and hyphen.

Finally, you mention but don't actually ask about SSH. If you mean OpenSSH (which is not the only SSH), FYI OpenSSH before 6.5 ssh-keygen actually uses OpenSSL libcrypto to write privatekeys in OpenSSL's 'legacy' formats (PEM types RSA PRIVATE KEY, DSA PRIVATE KEY, EC PRIVATE KEY) which also use EVP_BytesToKey with one iteration. But ssh-keygen and ssh and sshd using OpenSSL read routines can also handle OpenSSL's 'new' (circa 2000?) PKCS#8-encrypted format, PEM type ENCRYPTED PRIVATE KEY, which can use PBKDF2 with 2048 iterations through 1.0.2 (good around 2000, barely adequate now) and planned configurable up to INT_MAX in 1.1.0. OpenSSH beginning 6.5 (2014-01) has an option -o for its own (non-ASN.1 but still PEM) format using bcrypt, and forces that option for key type ed25519 (which OpenSSL doesn't support, at least not yet). (updates) OpenSSL 1.1.0 (2016-08) did add -iter N and optional -scrypt* for PKCS8 as expected; OTOH OpenSSH 7.8 (2018-08) made its own 'new format' the default; -o is no longer needed, and if you want to get the old and bad legacy formats you use -m pem.


According to nmap man page:

-A: Enables OS detection and Version detection, Script scanning and Traceroute.
-sV: Enables version detection, as discussed above. Alternatively, you can use -A, which enables version detection among other things.

It's the same as -O -sV -sC --traceroute.


What was the original intent for the feature that StrandHogg uses?

It's not just the victim "back stack". There are various possibilities. For example, let's say the victim app has not yet been launched. An attacker can place their activity in the background. Then when a user taps the icon of the victim app to start it, the "back stack" that the attacker's activity is lurking in could then come to the foreground and be treated as the victim's "back stack", just because of its declared task affinity.

  From reading the API description and the provided example cases the main intent of this API is to allow embedded activities from other apps to be displayed within your own task. However, the StrandHogg vulnerability seems to the other way around: using API to push your own activity over another task's "Back stack".

Regarding this use case, think of it this way: activity A is the intended embedded activity, coming from application 1. Application 2 is the one that would like to incorporate activity A. With the StrandHogg feature, application 1 can launch activity A into application 2's back stack, thus allowing the user the experience of activity A as an embedded activity within application 2, even though it is coming from another app. One can imagine that a legitimate use case would have application 2 first communicating with application 1 to request the embedding of activity A, and then application 1 using the StrandHogg feature to do so.

We could argue, and rightly so, that this is not the best way to support this kind of embedding, as it could be abused for phishing attacks and other attacks, but that's another question.


Does iOS use built-in certificates to authenticate peers when using ipsec VPNs?

I don't know about the specifics of iOS, but the principle should be the same.

In theory, if you get your clients to install and trust your CA certificate, then any certificate it issues will be trusted by those clients. A man-in-the-middle attack should not be able to forge these certificates, unless they grab hold of your CA private key. So in that respect, your solution should be protected against man-in-the-middle attacks.

The downsides of using such solution, as opposed to getting a certificate issued by one of the trusted root CAs is with:

Deployment : With your approach, you'd have to manually installed your own CA as trusted on all your devices. Users with other devices (without your CA certificate) won't have this installed and either won't connect, or will manually have to accept an unknown (and therefore untrusted) certificate. In which case, the man-in-the-middle attack is a real possibility.
Revocation : What happens if your CA or server private key gets exposed somehow. How can you tell all your devices not to trust it any more, and instead trust a new certificate? 3rd party trusted CAs usually provide service to perform revocation checks to avoid this. You might be able to do something similar on your own, but it increases the complexity dramatically
CA Security : Whilst this is not guaranteed, trusted certificate authorities are likely to have stricter security in place. This is their core business after all.
Price/Hassle : I imagine the cost of issuing a certificate to your server with a 3rd party trusted CA should be significantly lower than running this whole thing by yourself. This of course depends on your circumstances, e.g. how many devices, what security/resources you already have etc.


Rootkits and other backdoors

Short answer:

It depends on your personality, if you prefer security or comfort.
If you prefer comfort, you can download some free antivirus programs for Windows, or pay for some of them, and believe their reports. Than do not worry.
If you care about security, it is an insignificant question if you have a specific rootkit/virus running on your Windows computer, because it is very probable, that you have at least 2 or 3 built-in backdoors, and the long term solution will be leaving certain companies, like Microsoft and Google. You should expect no security or privacy with Skype, Windows or well known computer/phone brands.

Long answer:

I do not know in this specific situation, if you have Computrace, but I heared, that on Win machines it constantly keeps phoning back to company servers, which can be the reason of net traffic. Look for rpcnet.exe and similars. I do not know if it really works to block computrace on Win any more. Depends on your situation. Computrace is practically a built in BIOS spyware/backdoor for most modern computers which can monitor and take control over our device, like wiping the whole drive, etc. You should especially suspect this if you bought a used device.
The next I would say firmware spyware/backdoors, they are also official programs controlling your machine, like audio drivers, support apps and similar phising bloatware preinstalled andor needed for proper functioning.
It can be also Skype, try uninstalling it, and it will cause less crash, lag and probably net traffic too. Sometimes it also acts like a spyware.
Minimal traffic is normal when firefox is running. If you installed other apps, they also might call servers time to time.
If you have no backups, do that now, do a reinstall, do a virus check on the fresh system and your saved files, and start everything new with new passwords. This is the safest what you can do on Windows.

Tip/Solution:

Most of these things can be resolved by using Linux, and there are much more easy-to-use distributions in 2017.

It does not have to use Skype, there are opensource, multiplatform/protocol  secure chat programs.
Linux is less popular and harder to attack by viruses.
It is opensource, so harder to implement backdoors, unlike with Microsoft.
Linux has opensource firmwares, therefore the preinstalled spywares are deleted when you wipe your drive, and not needed to control your device.
Even computrace does not seem to work with Linux. You can not erase it easily from the BIOS, but it will be incapable to run.
There are opensource BIOSes outthere on limited hardware, but it usually needs hardware level knowledge.

Feel free to ask.


Rationale behind SELinux preventing file access

TL;DR

Set access levels for individual web applications.

Did read

After reading this page, I think I've got a good idea of the rationale. In SELinux, each file has a security context. You can view the current security context with ls -Z <path>, and set a new security context with chcon.

All web apps will be run as the apache user, so under normal circumstances, each web app will have the same permissions. With security contexts, you can confine the access of individual apps/script. By default, scripts have read-only access.

This is actually quite useful for security. Let's say you have an application you trust, which requires write access. You would explicitly give that script the httpd_unconfined_script_exec_t context. Now let's say you have an insecure application that is prone to exploits. You would leave the security context of the script(s) belonging to that application at the default, which prevents writing files.

Preventing file writes would prevent a whole range of attacks which exploit some vulnerability to write a script to disk, which can subsequently be executed over http by the attacker.


Eavesdropping in VoIP. Any other software besides Ethereal?

Ethereal was renamed Wireshark back in 2006 due to trademark issues.

Ethereal/Wireshark is just a packet capture tool with a GUI front end, there are many packet capture tools available. As to intercepting particular traffic, that would depend on particular network architecture and/or various attack methods that end up being a man in the middle.


What Enhanced Key Usages are required for PKI infrastructure tasks? (OIDs for OSPF and CRL signing, etc)

EKU is Extended Key Usage; this is a certificate extension described in X.509 (RFC 5280), section 4.2.1.12. As the RFC says:

  In general, this
     extension will appear only in end entity certificates.

because, contrary to "Certificate Policies", there is no notion of inheritance and propagation of EKU along a certificate path. The EKU extension tells things about possible usages for the public key in the certificate which features the extension, and only that public key. As such, your notion of "Root EKU" does not seem to make much sense to me.

As a general rule, lack of EKU does not prevent things from running, except in a few cases:

The certificate for a delegated OCSP responder (i.e. when an OCSP response is not signed by the CA itself) MUST have an EKU with OID 1.3.6.1.5.5.7.3.9 (see RFC 2560, section 4.2.2.2).
The certificate for a Time Stamp Authority MUST have an EKU with OID 1.3.6.1.5.6.7.3.8 (see RFC 3161, section 2.3, which also insist on the presence of only that OID in the EKU extension, exclusive of any other OID).

For other roles, the presence of the EKU extension is not mandatory, but shall be honoured if present. See for instance S/MIME Certificate Handling, section 4.4.4: if the extension is present at all, then the certificate should be considered as fit for S/MIME usage only if the 1.3.6.1.5.5.7.3.4 OID is present, or the special 2.5.29.37.0 OID is present (this is the "any extended key usage"). But lack of the extension is considered equivalent to an EKU with the "any extended key usage" OID.

There is no "extended key usage" for CA or CRL signing (for these, the basic "Key Usage" extension is considered sufficient).

Some systems can have extra system-specific requirements. For instance, for Smart Card Logon in an Active Directory context, certificates on the smart card and the certificates issued to the domain controller itself should both feature the Microsoft-specific 1.3.6.1.4.1.311.20.2.2. Microsoft are total fans of EKU; they even devised their own extension ("application policies", apparently not documented) which duplicates the information from the EKU extension.


vpn and strong authentication, how does the two work as a pair?

A Virtual Private Network on an end-user device (a PC for instance) is just that: a network which comes in addition to the ones you already have and which binds your client to a remote server/network though an encrypted tunnel.

It is set up after having received the authorization to do so in some way. This is usually bundled with the server/client solution you will use (and can be credentials, certificates, ...).

You should look at the VPN as an extension of the target network. You need to ensure you can connect to that network (the authentication part above) and then your traffic is similar to the one you would have in the LAN.

It is conceivable to have a VPN connection which is not authenticated. I fail to see a real usecase for that but this is to show that the VPN authentication is there to allow your client to connect to the target network (nor services).


How do I allow only app to view/download files from server?

You are asking two questions (I'm paraphrasing you...)

  Can I allow only my app to access my server?

No, this is impossible. You cannot control the client. Root  phone. Start debugger. Get your key. Create own app with your key.

  How do I secure my server?

Use a security framework for your app server. If, for example, you are using Java Spring, you could use Spring Security which handles authentication and authorization.


Are there any pen testing tools/methods for wpa2 networks that don't require using an adapter that supports monitor mode?

Practically speaking, no.

In order to break a WPA2-Personal network you need to capture a four way handshake. There are basically two methods to do this. In one case you simply eavesdrop while others connect, and when that connection is established the four way handshake occurs. The other option is to kick a client off of the network and again, capture the four way handshake.

In both cases you are capturing traffic that is not destined for your machine (mac address) and in most cases, you do not know the mac addresses of the clients that are currently on the network. For these reasons in almost every practical case to break into a WPA2 network you will need to put your network adapter into monitor mode*.

For WPA2 enterprise the scenario is completely different, but the answer is the same. In order to attack the network you need to set up a rouge AP. Although the steps for creating this AP technically don't dictate that you need to put your card into monitor mode; in order to know all of the configurations to successfully carry out the attack you will need to put your wireless interface into monitor mode.

*Note: If you do know the mac address of a client, and you have already connected to the network - it is possible to change your mac address to that of another client and receive their packets without the use of monitor mode. But then you're not really attacking the network are you?


Accidently opened a phishing email, is my computer infected by malware?

You are most likely safe. As you said, the objective of those phishing emails is to trick you into believing their website/email is legit so you interact with them and give them your data. The chances of them injecting malware on your computer that can run without being executed and not being picked up by all those AV solutions that you used are minimal.

That being said, the real problem here is your options. You can not claim to care and worry about computer security and have your email auto load remote content. You should turn it off immediately. Most email attacks, other than phishing, rely on 3 things that you are absolutely under control.

Do not download files that you are not certain about.
Do not auto load remote content.
Do not display emails as original html. Go with either plain text or simple html at least.


Is that a tool dedicated to accessing rtsp streams over IP?

There are various Metasploit modules that can be used for RTSP depending on the application using this protocol.


Search engines
Around 2:19 you can see the file name in the top of the pdf reader. Putting this between double quotes let's the search engine search for that exact phrase:
Google
I also tried Bing and Duckduckgo, but they don't give anything either.
Meta search engines
If we try meta search engines (special search engines that combine the results of multiple normal search engines):
Dogpile
I also used Excite and Deeperweb, but they don't result in anything either. Besides using the exact phrase method, I used the following:
"inurl:no inurl:malware inurl:here filetype:pdf"
(without double quotes), but that also gives nothing. Because of this I think an exact copy of the document he uses isn't available on the internet.
Let's mess around
Wikipedia tells us that heap sprays can be implemented using JavaScript and/or images. Both of which can be used inside a pdf file. If you're really interested, you could search for general tutorials on heap spraying and on using JavaScript inside pdf documents and try something out yourself.


What Mechanisms Keep Network Processes (and Applications) Sandboxed

What you are talking about deals with a few different layers of the OSI model:

At layer 7 (Application) you have your web-app starting to communicate with the bank's host (as an example). It initiates a request for communications that is handled by Layer 5 (Session) that creates and maintains the communications channel between the applications. The result is called a socket in common terms. All of the transported data is handled by layer 4 (Transport) which in turn is directed by Layer 3 (Network) which guides the ethernet frame/IP Packet to it's destination, all of which flows through layer 2 (DataLink) which is responsible for handling the modification of the frames for transport onto Layer 1 (physical) the wire or wireless communication.

Layer 6 (presentation) converts or modifies the data being sent, so that it can be understood at both ends by the applications using the data.

Each application running, that requires network communications, goes through that sort of process, and information from each socket is given to the application that opened it. As for most non-malicious programs, they (probably) do not obtain or view information sent to you on other sockets. So, to answer your question, generally there is no reason to not run multiple applications simultaneously. Java-based apps still use their own sockets, and the OS handles which information goes where.

However, since ALL of your information goes through a common layer 2 and layer 1 section, (NIC / Wire / Radio), it is possible to craft applications that can capture and record ALL NETWORK TRAFFIC locally on your machine. (In fact many exist, take Wireshark for example) Since that is the case, it is very possible for some applications to view or take actions based on that captured data. There are a few other attacks that can be used to hijack the session(socket), and obtain the information at that level as well.

What can be done to secure it?
Encryption of the data at different layers can prevent capture of readable or usable data by programs that might want to "peek" at your information. But that is a much different monster and comes with it's own fun bits.

I'm relatively new to the whole networking thing, but understanding the OSI model and how it conceptualizes networking goes a LONG LONG way towards understanding it.


In mysql you need a white space after comment marker. Just put one whitespace character after --.

select * from users where login='admin' -- now you can add comment

Generally add trash character after the whitespace against trim function. Like;

admin' -- xx


How can privilege escalation through pkexec be prevented?

Configuration, basically.

If you're on Ubuntu, have a look in /etc/polkit-1/localauthority.conf.d/51-ubuntu-admin.conf:

 [Configuration]
 AdminIdentities=unix-group:sudo;unix-group:admin

Any member of the unix groups sudo or admin can use pkexec to gain administrative capabilities. The user created during installation of Ubuntu is a member of those groups, as it is the system administrator. If you create a new user that is not member of those groups, it cannot use pkexec.

man polkit gives you some information about how to configure policy kit.


Landlord will be watching my data traffic, as mentioned in the lease agreement

FINAL (hopefully) UPDATE: Well after all the very interesting and valuable discussion, it seems to me as though initial thoughts were correct. From the updated question, I would say that the restrictions are pretty standard for Germany.

My recommendation is that you ignore the noise and the concerns and simply make use of the service. Unless you have some very specific security needs that you haven't shared, using HTTPS wherever possible (which is best practice anyway) is sufficient.

In any case, the other options discussed would all add overheads to your traffic which would use up your 30GB even sooner and slow things down.

There are several things you can do. Provided that the terms and conditions of use are OK with them.

You don't say what country you are in but you might want to get the terms of use checked by a lawyer since some terms may not be legally permissible anyway.

Here are four of the main ways you can protect your Internet traffic from the prying intermediate.

Make sure you always only connect to HTTPS sites

When you use HTTPS sites, the traffic is encrypted between you and the endpoint. Your landlords infrastructure will not be able to do more than examine the destination IP address, port and DNS. In particular, things like banking and health sites will remain secure.
Use a VPN

A VPN in this case is a 3rd party service that encrypts ALL of the traffic (not just web traffic as in 1) between your machine and the VPN host. This prevents any inspection of the traffic at all and it will appear as though you only talk to the VPN destination.

Unfortunately, it is possible that common VPN end-points might be blocked or even a smart security system used that will dynamically identify VPN traffic and ban it. Check the terms of use from your landlord carefully.
TOR

TOR is a way to obfuscate connections across the Internet and is often associated with "the dark web". However, it has legitimate uses as well. Unfortunately, it can add quite an overhead to traffic and may be unacceptably slow. Typically TOR will be used for web browsing, other network traffic would not be affected.
Use the Mobile network

If you are fortunate enough to live in an area with a) good (4G/LTE) mobile coverage and b) an affordable data tariff. Then using a 4G/LTE mobile router may be an option. You can get some staggeringly good data rates.

Don't expect to be free of restrictions though. Many tariffs don't allow device sharing, you'll need a special tariff for mobile data. You might not be allowed to use all services (like VPN's) and you are more likely to have national-level restrictions applied such as the UK's national "firewall".

It goes without saying (so I will say it anyway!) that you should ensure that you are staying within the letter of the laws of your locality & the legitimate terms of use of the landlords network. However, none of the above are illegal in most countries (well in most Western countries anyway) as long as you are not using them to do illegal activities. TOR and VPN's may possibly be illegal or at least get you unwelcome attention in certain countries.

UPDATE: Without question, the most security would be provided by a VPN.

However, that will only be useful if the landlords network allows VPN traffic. In addition, VPN's also carry an overhead so things like real-time traffic (Skype voice/video for example) and online gaming would be impacted quite significantly.

In addition, VPN's will normally come at a cost though there are some discount codes around that might help.

It is possible to set up your own VPN if you have a server on the Internet to run it on. Most VPS hosts wont allow it but some will as long as you keep it private.

The real question is - do you really need to be bothered? That's why I mentioned HTTPS first. Since this protects your information to sites and since all decent online services already use HTTPS, you might find that this is a storm in a teacup.

UPDATE 2: As some others have pointed out. There are many flavours of VPN. A commercial service will be the easiest to consume but you need to do your homework to find the best for your region. Commercial VPN's can also be relatively easily blocked both by end point and by traffic inspection. Some VPN's require specific ports to be open on the network and these might not be available. Test before you buy. In general, those offering SSL-based or OpenVPN-based are likely to offer more options and be easier to get through any blocks.

Another form of VPN is to use an SSH client such as PUTTY (for Windows) connected to an SSH server (perhaps on your own or a friends VPS). You can throw in a local SOCKS proxy client and then you will have a very configurable private VPN service. Not especially easy to set up though if you don't understand the terminology. Note that many VPS services ban their use for even private VPNs.

Another thing to note is that there are several ways for security infrastructure to spot VPN traffic and therefore block it. Known end points for commercial services and known ports for VPN types are the easiest but it is possible to examine traffic patterns and work out that even apparent SSL traffic (e.g. if using port 443 for VPN) isn't actually.


The main reason for getting hardware firewall is also not because the computer is directly vulnerable to attacks, it's because you need a fast performing device, which is manageable and has the ability to do complex filtering. Getting a hardware firewall for just one computer is a bit silly.

The amount of possible attack vectors is reduced as less various attack surface is present.  A firewall has a lot less applications running than a computer in the first place. Also a firewall which is correctly placed in a network does not have its administrative interfaces (which manage the firewall) facing the internet. These are managed from a seperate, restricted network.

This means that you would need to be able to have some kind of buffer overflow when it checks the incoming connections. This would be possible theoretically but the likelihood is  quite low. I'm not saying impossible, but lower.


How does virtualisation (IaaS) protect from CPU microcode updates and firmware changes?

Yes, I think it is safe to assume that a VM will prevent guests from updating the CPU microcode of the physical CPU.

Updating the microcode on an Intel CPU involves executing the WRMSR instruction, with MSR 0x79.  This is a privileged instruction, and can only be executed when the CPU is in privileged mode (CPL=0).

The virtual machine monitor (VMM) should trap on all privileged instructions, including this one, and take appropriate steps to emulate it.  While I haven't checked the code of any VMM, I would expect a reasonable VMM might refuse the update, or might ignore it, but no reasonable VMM should allow a guest to update the microcode of the physical CPU that the host is running on.  It would be pretty surprising for a VMM to allow a guest to request a microcode update and to actually execute that request on the host CPU.

Updates to firmware of other hardware peripherals is a trickier question.  The answer will depend upon how the VMM manages access to that hardware device.

If the hardware device is emulated or virtualized, then a reasonable VMM should prevent a guest from loading firmware updates into the device (in a similar way: loading a firmware update requires I/O to interact with the device, and a VMM should restrict I/O with the device).

However, if the VMM provides the guest with unrestricted direct access to the hardware device (i.e., direct assignment of the device to that guest), then I suspect that the guest might be able to load firmware updates, if the device permits it.

The virtualization strategy for hardware devices will be dependent on the specific VM you use; some VMs use emulation or virtualization, but some may also use direct assignment in some cases.  I am not an expert on this subject and cannot speak authoritatively about it.  If you are concerned, choose a VM that provides full virtualization or emulation of all devices, and does not use direct assignment to give a guest direct unrestricted access to any hardware peripheral.

References:

See the Intel® 64 and IA-32 Architectures Developer's Manual: Vol. 3A , Section 9.11.6, for a description of the procedure for loading CPU microcode updates, and Section 9.11 for CPUmicrocode updates generally.


What is the right strategy for me to develop a paid public wifi?

You should use WPA2-Enterprise, it allows you to issue per-user credentials that can be revoked at will, in addition to using unique keys for each user (so you can't decrypt someone else's wireless traffic even if you are allowed to access the network, something possible with WPA2-Personal where the key is the same for everyone).

You'll need a RADIUS server which will handle authentication attempts (every time someone associates with the AP, it relays the authentication information to the RADIUS which decides whether to accept or decline the request). This server keeps (hashed) credentials in a database and you can add and remove them at will, possibly automatically by using a payment gateway. You can even serve a second, open Wi-Fi network which only allows access to your signup page (over HTTPS) so people can sign up and pay for your network by themselves without asking you. Once they paid their credentials are added to the database and they can connect to the secure network.


Should I use AntiForgeryToken in all forms, even login and registration?

Yes, it is important to include anti-forgery tokens for login pages.

Why?  Because of the potential for "login CSRF" attacks.  In a login CSRF attack, the attacker logs the victim into the target site with the attacker's account.  Consider, for instance, an attack on Alice, who is a user of Paypal, by an evil attacker Evelyn.  If Paypal didn't protect its login pages from CSRF attacks (e.g., with an anti-forgery token), then the attacker can silently log Alice's browser into Evelyn's account on Paypal.  Alice gets taken to the Paypal web site, and Alice is logged in, but logged in as Evelyn.  Suppose Alice then clicks on the page to link her credit card to her Paypal account, and enters her credit card number.  Alice thinks she is linking her credit card to her Paypal account, but actually she has linked it to Evelyn's account.  Now Evelyn can buy stuff, and have it charged to Alice's credit card.  Oops.  This is subtle and a bit obscure, but serious enough that you should include anti-forgery tokens for the form action target used to log in.  See this paper for more details and some real-world examples of such vulnerabilities.

When is it OK to leave off the anti-forgery token?  In general, if the target is a URL, and accessing that URL has no side effects, then you don't need to include anti-forgery token in that URL.

The rough rule of thumb is: include an anti-forgery token in all POST requests, but you don't need it for GET requests.  However, this rough rule of thumb is a very crude approximation.  It makes the assumption that GET requests will all be side-effect-free.  In a well-designed web application, that should hopefully be the case, but in practice, sometimes web application designers don't follow that guideline and implement GET handlers that have a side effect (this is a bad idea, but it's not uncommon).  That's why I suggest a guideline based upon whether the request will have a side effect to the state of the web application or not, instead of based on GET vs POST.


How was Lowe's website exploited to steal merchandise?

Press reports don't go into much more detail than this:

  They employed a online scheme known as “glitching” – exploiting a weakness in online retail websites by logging in coupon codes that wrongly bring goods at dramatic discount or for free, store investigators said.

(Source)

This sounds like a calculation error in their web shop software or human failure. E.g., an employee might have mistyped a 10% discount coupon as 100%. The couple probably discovered that bug by accident and presumably neither of them has an information security background.

  How is it their fault if Lowe's sent them free items?

Come on, you don't need legal expertise to agree that repeatedly exploiting an obvious mistake by the retailer is fraud.


compromising DVRs to become bitcoin mining bot

The echo is a shellcode that gets executed on the DVR. It stores a little file that is a program acting like wget. This program then gets called to fetch an other one (the mining program) that gets executed.

Sorry I was mistaken. As pointed out in the comments, please look at this thread A tiny version of wget (51 bytes?)


Is there a specification for the color values representing information classification levels for the United States?

Ok so after diving into this a bit, this is the best I can come up with. I do not work for the US government so I cant say anything with any level of confidence. However;

It seems that the color classification system is largely based on convenience. Since the whole point of having the classification marked on the pages of each document provides a simple method to check the clearance of the person with the requirements of the information. However, in the case where only text is used, it becomes difficult to assess at a glance whether someone is holding something they shouldn't. Hence, the color coding.

I started with a document referenced by the DoD Guide to Marking Classified Documents where on page 39 make reference to SF labels, this document makes a reference that points to DoD Directive 5200.1-R which states on page 59 Section C5.4.10:

  C5.4.10.1.
  If not marked otherwise, AIS storage media and other items covered by this section must be marked with the following labels:

  C5.4.10.1.1. SF 706 - TOP SECRET

  C5.4.10.1.2. SF 707 - SECRET

  C5.4.10.1.3. SF 708 - CONFIDENTIAL

  C5.4.10.1.4. SF 709 - CLASSIFIED

  C5.4.10.1.5. SF 710 - UNCLASSIFIED

I also found a training document in the archives that shows pictures of these labels with the colors you describe on slide 46, also mentioning the SF codes of the labels. The slide also mentioned a reference in the line above the labels:

  Within a classified environment, the following labels are authorized for use:

  (Ref: 32 CFR 2001.80)

If we look at gpo.gov we find Document CFR 2001.80 which states on page 539, Subpart H, Section 9:

  (9) SF 706, TOP SECRET Label: The SF 706 is used to identify and protect electronic media and other media that contain Top Secret information. The  SF 706 is used instead of the SF 703 for media other than documents...

Looking up SF 703 on gpo.gov gives the full details of 703, no colors are mentioned but it does state an inventory number in subsection (e) along with the date of the document:

  (e) The national stock number of the SF 703 is 7540-01-213-7901.

  [50 FR 51826, Dec. 19, 1985]

Alas if we look for that on the government archives we see that we can't simply view the requirements for these or view examples as:

  The following forms are available to U.S. government agencies, but cannot be placed on the website because of unique construction. It can be ordered by calling Global Supply customer assistance...

And if we look at the GSA for 703 specifically we see that authorization is required to get your hands on them, which makes sense given that they are meant to mark classified materials. However note the date also listed here:

  Current Revision Date: 08/1985

We now have two sources that cite label SF 703 as having an inception date of around 1985. Lets take a look at the state of computers at that time. If we go to Wikipedia we can find a list of the history of color pallets for this time period (give or take). The pallets were very minimalistic.

What I think you are seeing here is the product of an old system being used to this day without having its definitions adapted. It's possible that SF 703 and its sister labels have a definite hex value, but that information would be held by the GSA, and i doubt they'll disclose it. But it seems to me that the reason you only see generic references to "orange" or "yellow" is because there was no ambiguity then about what that meant (think 16 color pallet of MS paint except from 1980's-1990's) red, orange, yellow, blue and green were easily recognizable on print media and very hard to mistake.

Long story short, there could be an exact value definition, but i doubt it. I think this is just a color coding scheme where the colors were picked a long time ago at a time where 16 color pallets were a thing and have been used ever since. Whatever "red" they used in 1985 is probably exactly the same one used today. It is not strictly in the definition of any classification system documents because it is meant to be an aid not a definition itself. Something to easily see "AH the document in his hand is yellow, but he has a red badge. Something is wrong." rather than a strictly defined principle as the actual word "SECRET" is.

Of course again, this is just based off what I saw when I dove into the subject. I could be wrong. Maybe there is some definition out there. But this is what I think. It was a fun little research though!

Now all I have to do is prepare my statement for when the NSA/FBI come to my door asking why I've been looking up and down the GPO, GSA, Gov Archives and Pentagon sites looking for Classification materials and Directives from the DoD...


Your client will usually perform the same checks. Get the certificate, and check that it can trace it back to a known root certificate (possibly via one or more intermediate certificates, forming a "certificate chain").

This is the case with curl for instance:

you can specify the list of acceptable CA certs using the --cacert option
you can disable the check using --insecure (or -k)

The list of acceptable root certificates may vary from one tool to another (it may also depend on the operating system). Some will use a system-wide list, while others will use their own list.

Some tools may not do the verification automatically (or at all), but you'll need to give us details of the specific tool if you want more details.


Why does my Charter cable modem have a static ARP entry tied to a Department of Defense IP?

My guess is that your cable modem or cable provider is using this address space internally for some purpose because the 22.0.0.0/8 space is non-routable.  From: http://blog.erratasec.com/2013/12/dod-address-space-its-not-conspiracy.html#.WPgyoHXyvrc

This sort of thing happens a lot. I (or others I trust) have seen 1.0.0.0/24, 22.0.0.0/24, and other instances of 30.0.0.0/24 used this way. I can confirm that companies use DoD address space as private addresses. Just because it's DoD doesn't mean they route to the DoD.

The reason all these address spaces are DoD is because that's really the only source of unused IPv4 addresses left. All IPv4 address ranges have been assigned. But, the DoD has been assigned 20% of the IPv4 address space, but most of it is used within the DoD, on their own private networks, and is not routable to the outside world. Thus, if you are looking for a large chunk of "private" addresses that won't suddenly one day be assigned to Akamai or Amazon (and thus, explode in your face), then DoD addresses are the way to go.

You can confirm this by trying to route some packets to these addresses.  Use traceroute, where do they go?  They should go nowhere.


AES-ECB chosen plaintext attack with long secret

I think you already said the solution in your post but let's repoint it.

AES work with block size of 16 bytes (128 bits)
The secret is appended to a text that you choose.
???
Find out the characters of the secret string one by one

If it was not an exercize I would give more details...

EDIT

Once you find the first 16 bytes, all you need to do is :

Exactly the same thing but look at the second block!

The solution...

Get the first secret block

Enter 15 characters and retrieve the first 16 encoded bytes
Then enter 16 characters changing the last one until you get the same result as with 15 characters for the first 16 encoded bytes. That 16th character is the first character of your secret. You can then repeat the process by putting 14 characters and then finding the second secret characters with the same thechnique.

Get the second secret block

You already found the first 16 secret bytes. Now enter 15 characters and find the result for the second block of encoded bytes; bytes 17 to 32. Then enter 32 characters, only changing the last one until you find the 17th secret characters in the secret string. Then repeat to find the 18th and so on byte.


Invalid Certificate when adding Gmail account to Apple Mail

Renew the certificate on the domain, if you can't contact the administrators.


What are the security benefits to block all http referer header requests for web browser?

Is this a security benefit

It serves no real security purpose, but it serves a privacy purpose.

By blocking the referrer then the sites you visit will not know what site you were previously on (maybe my visit to a clothing website was due to a link I found on a deviant sexual forum discussing how the clothing company has a sale on?).

A lot of companies especially commercial businesses analyse where traffic is coming from to their site, so the prospect of someone seeing a referring page URL is higher than you might think.

Often of course you will have got to the site with your search engine, so the search engine terms will typically be in the address bar and will be accessible to the site. If I searched "how to trick speed cameras" and the most relevant page was on my local police force's website talking about "speed cameras" where they list "how" many they have rolled out and how the new models are harder to "trick" then the search engine might have thought my terms were relevant but I have provided information I did not wish to share with that site (even though I am not ashamed of my choice of search engine, it's the URL which is private).

Finally, to use Tomasz's internal example but to use a scenario more likely, if you got to the link via a company web-page (http://ibm-intranet/Bus_Companies) then it reveals more information about me than I had intended (the fact I potentially work for IBM) to the site I visit.

For me the HTTP referrer represents no risk, but others may feel more comfortable blocking it.

  Will sites loose functionality if you do so?

Some sites hate hot-linking to images or files, so they will not allow access to images or files unless the HTTP Referrer states it came from their site and not some other site that happens to be using their resources (both the content and bandwidth) in a way it was not intended.

This wiki link about Referer Hiding (spelt incorrectly in the standards so "Referer" is correct) may be of interest


Verifying one specific attack vector of Cross Site Scripting

This looks like it could be exploited using a cookie value like this

</script><script>alert(1)</script>

Try setting it manually and see if it fires the alert.


How to prevent exam cheating in computer labs using remote access software

This type of thing is solved by configuring a firewall to block the connections. But the lab runs the firewalls. So, there would have to be government-managed firewalls for this solution to have any integrity.

The same problem applies to trying to prevent installations. Whoever can physically touch the machines, owns the machines. The government would have to run these labs.

The one thing that could be done is to work with ISPs to monitor and report on these labs when there is unauthorised traffic. This would invalidate the lab and the exam results, but the students who paid for the exam might end up losing their fees.


The official term for an attacker eavesdropping on your connection using a different certificate is called Man-In-The-Middle attack in this scenario.  The way to protect from this is pinning. An overly simplistic explanation is to check a certificate against a hardcoded copy of the original one. For more details, see the above link. My suggestion is to go with this approach as long as you control the corresponding servers.

However, to specifically answer your questions:

1) Keep in mind that hashing is meant to be one-way, so depending on what you want to do with the data it might become useless after hashing.

2) you can add another layer of security by encrypting the data end-to-end. I suggest public key crypto since you dont need to ship a shared key but just a public key with the client.

3) Completely unrelated question, but fine. JS can be increadibly mean if you have a look at code almost completely constructed from brackets and +, so you can somehow defend against reverse engineering. BUT there is no perfect obfuscation, this is an arms race


SCADA / PLC exploit code was released in metasploit. Now what?

This just brings into the public eye something which has been happening for ages: everything is vulnerable. SCADA kit used to be safer as it generally wasn't connected directly to public networks and was considered obscure, however the targets are juicy, and the security levels generally pitifully low so attackers have always researched ways to exploit them.

The broad concepts to prevent attack are the same as for anything else

segregate networks with access control devices (routers, firewalls etc)
secure communication links (encryption, authentication, and yes, removable media!)
harden platforms and applications
review code
penetration testing

In respect to your sub-questions:

if the PLC's are not connected (and you can confirm this) then they can't be attacked through a connection. However most are connected through some type of link, so assume that link is the attack conduit
PLC's are a specific area for this Metasploit update, however you should generally assume any system has vulnerabilities and plan accordingly based on your risk appetite.


Untrusted signature on java app for downloading youtube, harmful?

Well, there's no way to know that for sure without looking into the application...
Although, it does seem incredibly suspect.

This message lets you know that your browser is trying to launch an applet in trusted mode, which means that the Java code will have full control over your system.
You probably shouldn't accept, unless you know (and trust) the publisher.

...Which is exactly what the warning says.


Best way to check if your browser is secure

I believe when you talk about "malware checking software which seems is just a virus" you mean the pop-ups that appear on shady websites and that say "Your PC is infected/slow/malfunctioning, download this software to clean it!". This software is indeed malware (or, at its best, useless crap) and you should never download and run it.

Always rely on legitimate sources for antimalware, e.g.:

F-Secure
Kaspersky
Symantec
Avast

to name a few.

Since there's a high risk your computer is infected, you must stop using it immediately, wipe it out and perform a clean installation from a clean CD/DVD, as said in the comments.


Reversing an entry card - How to find out what type of RFID hardware I need to read the chip?

You only need one RFID device, its the Proxmark3.  There are many protocols and frequencies used by RFID and the Proxmark3 tries to support all of them.  It is open source hardware and software and breaks every commercial RFID card I know of.  The real problem with RFID is that you have a very limited power usage so you are forced to use weak crypto systems.   Often times they rely upon security though obscurity, and the Proxmark3 is designed to overcome this.


What happens when certificates further up the chain expires before mine? (Equifax/GeoTrust)

GeoTrust (and RapidSSL) certs have two trust paths.
There is a root cert for GeoTrust Global CA valid 2002-05-21 to 2022-05-21 and now widespread,
and also a "bridge" cert for the same CA valid 2002-05-21 to 2018-08-21 chaining back to Equifax Secure Certificate Authority which as you saw is valid 1998-08-22 to 2018-08-22.
See my (updated) answer to google certificates correct CA .
So yes your cert will be invalid for its last few days if using the bridge+Equifax chain.

This also affects OCSP responses in your non-title questions.

I don't have a rapidssl cert to test, but if I ask gtglobal-ocsp.geotrust.com about google-CA the responder cert is also under GeoTrust Global CA.
If rapidssl-ocsp does the same, OpenSSL should verify the response if the truststore
contains the GeoTrust root but not the bridge cert because that can confuse chain lookup -- at least to date; 1.0.2 is announced to have changes in chain validation and I haven't looked at the details yet.

For server certs AFAIK all major browsers trust the GeoTrust root and will chain to it. I don't know they validate OCSP responses the same way (as server certs) but I would hope and expect so.

But note if your server (is configured with and) provides in handshake the bridge cert, and possibly the Equifax root -- root is always optional and unnecessary in handshake, OpenSSL client (to date as above) must have the Equifax root in truststore, it will not "discover" the alternate and better trust path to the GeoTrust root, which browsers and maybe other clients will.


It's an automatic probe to see which URL syntax, if any, you support.  They're trying raw HTML, two versions of BBCode, and a bare URL, all with unique URLs.  They'll then scan your site (either directly or indirectly, eg. through Google) to see which ones, if any, have been turned into working links, in order to guide actual spamming.

Since the whole thing is automated and is probably running on a botnet of hijacked computers, perpetual failure doesn't cost them anything.


Is it possible to execute xss when response is of content type:application/json in latest IE?

XSS is still possible even in newer versions. But it depends how the JSON is used. The article you reference cares only about executing JSON by itself, i.e. accessing a JSON document via a link.

It does not discuss the case when you return JSON from an XHR request and then include the received data directly with document.write or even interpret it with eval. In this case of full trust in the validity of the JSON XSS is still a problem. No content-type sniffing will be done because the web application inside the browser knows what it should get and will interpret the content itself, i.e. not the browser will render the content.

XSS is also possible if the JSON is included with a script tag. In this case browsers accept (almost) all content types and no sniffing is done because again the browser knows already what the content should be from the context.


Can I have push notification authentication without a third party app?

When you are using SMS, you are authenticating the user's sim as the additional factor. Whereas in case of push notification, the user's mobile device is acting as the additional identity provider.

You can definitely use push notification from your app to authenticate the user's mobile device and will not be missing on any functionality from security point of view. Apps like authy provide more convenience to the user as it provides second factor in different forms and not just push notification. For example, push notification might not work when the device do not have an active internet connection. Apps like authy or google authenticator also provide the time stamp based soft tokens that works even without internet.

If more people go with authy you can safely assume that many of your users have it by default and it doesn't act as an additional barrier for most of your user base. It is a trade off  on convenience than security on whether to go with authy or any other third party vs. sending push notifications via your own app.


Does "loose source and record route" drop the source address?

To complete the message from @mr.spuratic: the text from RFC 791 is:

  Loose Source and Record Route

    +--------+--------+--------+---------//--------+
    |10000011| length | pointer|     route data    |
    +--------+--------+--------+---------//--------+
     Type=131

    The loose source and record route (LSRR) option provides a means
    for the source of an internet datagram to supply routing
    information to be used by the gateways in forwarding the
    datagram to the destination, and to record the route
    information.

    The option begins with the option type code.  The second octet
    is the option length which includes the option type code and the
    length octet, the pointer octet, and length-3 octets of route
    data.  The third octet is the pointer into the route data
    indicating the octet which begins the next source address to be
    processed.  The pointer is relative to this option, and the
    smallest legal value for the pointer is 4.

    A route data is composed of a series of internet addresses.
    Each internet address is 32 bits or 4 octets.  If the pointer is
    greater than the length, the source route is empty (and the
    recorded route full) and the routing is to be based on the
    destination address field.

    If the address in destination address field has been reached and
    the pointer is not greater than the length, the next address in
    the source route replaces the address in the destination address
    field, and the recorded route address replaces the source
    address just used, and pointer is increased by four.

    The recorded route address is the internet module's own internet
    address as known in the environment into which this datagram is
    being forwarded.

    This procedure of replacing the source route with the recorded
    route (though it is in the reverse of the order it must be in to
    be used as a source route) means the option (and the IP header
    as a whole) remains a constant length as the datagram progresses
    through the internet.

    This option is a loose source route because the gateway or host
    IP is allowed to use any route of any number of other
    intermediate gateways to reach the next address in the route.

    Must be copied on fragmentation.  Appears at most once in a
    datagram.

Possible confusion arises from the reuse of the the expression "source address". An IP packet has a source address field and a destination address field, which are NOT part of this option. The contents of the option (route data in the diagram above) consist in a sequence of IPv4 addresses, and the pointer field is an index within that list.

When the packet is first emitted, the sender wishes (by this option) to direct the packet to go through a sequence of designated routers. Let's call i1, i2... in the IP addresses of these routers; let d is the final destination for the packet, and s is the sender's own address. The packet will be allowed to traverse intermediate machines not in the list (that's the difference between "loose source and record route" and "strict source and record route").

A router is, by nature, "between" two (or more) local networks, and has one IP address on each. So the address ik for router k is one of the addresses of the router; the packet sender is expecting the packet to enter that router through the local network which contains ik.

Initially, the source address field is set to s; the destination address field is set to i1; and the loose source and record option contents are set to i1, i2,... in, d. The pointer field points to i1.

When the packet reaches router 1, the router notices that the destination field address matches one of its own IP. It then does the following: it replaces the destination field address with the next IP in the list (i2) then records its own address in the list: where there was i1, router 1 puts o1. What is o1 ? It is the output address which router 1 will use, that is the address on the other local network on which the packet will next be emitted. It is an address of router 1, just like i1, but on its "other face". The pointer field is also incremented, so that it now points to the slot containing i2.

The process continues until the last address is reached. Namely, when router n was reached, it wrote d in the destination address field, and wrote on over the value in in the option. When the final destination host is reached, the option contains o1, o2,... on, d. But the source address field (which is not in the option) has remained untouched throughout the whole process; it still contains s, the initial source address.

The idea of source recording is that the destination host could respond to the source host by sending a packet with its own "loose source and record route", and may use the recorded addresses so that the packet follows the same path, in reverse order; the answer packet would initially contain:

source address field: d
destination address field: on
loose source and record route contents: on, on-1,... o1, s

The "output address" of each router is now the "input address", since the answer walks the path in reverse order. And the routers will then put back the
ik addresses on the way back. And so on.

What's the point of this option ? Conceptually, it replaces Network Address Translation; or, more accurately, it implements NAT with the "address translation" using some state information which is in the route option itself.

Imagine that the initial sender A has address 10.0.7.34 (a private address in a local network) and wishes to contact external host B with address 237.23.56.171. The sender knows an "exit gateway" G which has a private IP (10.0.1.1) but also an external IP which is "on the Internet" (say, 243.157.4.28). Thus, the sender uses the loose source and record route option to indicate that the packet should do through 10.0.1.1. The destination host then receives a packet which comes from 10.0.7.34 (an IP address which makes no sense to the destination host), but which recorded that it went through 243.157.4.28 (that's the address that the "exit gateway" recorded in the option when the packet went through it).

The B host can then respond to A by using the same option, indicating passage through 243.157.4.28 (the external facing address of G). The final destination address for this answer is 10.0.7.34 which has no meaning for B (it is a private address in another network), but the packet will first go to G, and G knows everything about 10.0.7.34.

That way, millions of machines in a private network could "share" the external address of G, and all be able to contact external servers. One may even do connections between two hosts who are on distinct, private networks, by using source routing through two gateways.

When doing NAT, there must be some state somewhere, which remembers the translation to perform. In NAT as it is commonly used, this state is tables in the router G. G will play with the ports (an UDP/TCP concept) to keep a reference, but the actual state, i.e. the addresses which must be used and replace the ones written in the packets, are in G's RAM. The loose source and record route option allows for putting that state in the packets themselves, thus allowing G to handle millions of combinations without using any RAM at all (and when IPv4 was designed, RAM was very expensive; in 1981, when RFC 791 was written, 64 kB was huge).

However, putting state in packets means that the state could be altered externally. In 1981 everybody on the Internet was cooperating. In 2013, there are bad people. Evil people. Attackers. These people may use the source and record route option to make packets go through unexpected routes and artfully dodge firewalls. It is possible to implement and configure firewalls to inspect and block packets which use the source and record routes, but it requires more thinking. Sysadmins don't like that. They prefer usual NAT where all the state is on their machines, because it makes the problem simpler. So source routing has been deprecated in the 1990s. IPv6 designers tried to revive it, but it is encountering the same lack of support from firewall vendors and sysadmins, who prefer to kill it right away.


Are mitigations for Spectre and Meltdown needed in the VMs for dynamic languages other than JavaScript?

As long as a VM doesn't execute an untrusted code, no.

Note that "executing untrusted code" includes taking code snippets from Github, StackOverflow or elsewhere and running them in a sandbox of any kind, like: a chroot, an isolated container or a virtual machine (but except a browser sandbox, like Brython or Emscripten, once proper browser mitigations are in place).

If a VM can under any circumstances execute an untrusted code, the answer is: it depends. It's still possible that it doesn't need all or any of the mitigations a JS engine now features, but your threat model becomes much more complicated.

As of now, a few requirements must be met for your VM to be theoretically exposed to Meltdown or effects of Spectre:

The VM runs an untrusted code which can, at least, send messages to the outside world.

Including, but not limited to, Internet access or permissions to display or write data to a location which could later at some point be accessible by an attacker.
The VM allows usage of high precision timers or tools that could be used to measure relative execution time of the respective programming language instructions.

Including, but not limited to, buffers shared between concurrent threads.
The VM features optimization techniques that, at least theoretically, could allow the untrusted code to run with approximately the efficiency of compiled code.

Including, but not limited to, just-in-time (JIT) compilation or optimized bytecode generation.

It is believed[citation needed], that at least in case of CVE-2017-5715, under certain circumstances (e.g. presence of particular binary instruction sequences in system libraries and a series of unfortunate events), this particular requirement could be further relaxed or lifted.
Any of the following conditions are met:

OS mitigations for Meltdown are not applied
The VM loads a sensitive information in the same process where the untrusted code snippet could run
An attacker can supply some input into any other process (which has a sensitive information in its memory and runs on the same physical system the untrusted code runs on) at the same time while the untrusted code is running, from the untrusted code itself or by any other means, directly or indirectly

If all four conditions above are true, then, theoretically, your VM could be used to extract a sensitive information from your system, based on effects of Spectre and/or Meltdown.

A simple example of a virtual machine which, albeit effectively often running a third-party code, is not exposed to Spectre is the TrueType glyph hinting language VM which doesn't allow threading or instruction timing in any way, thus breaking, at least, the requirement #2.

  An important note on system updates.

  In case of Javascript PoC, Meltdown or Spectre aren't used to read either kernel memory or memory of other processes. They can be, but the main issue with Spectre in Javascript VM is that the VM runs in a sandbox (meant to be isolated and safe before) within a browser process which contains sensitive data (Web site passwords, cookies and so on).

  OS updates (e.g. KPTI for Linux) won't help to mitigate the issue completely, because:

  They target Meltdown while the main issue is Spectre;
  The only thing KPTI guarantees is that a process wouldn't be able to read kernel memory (and memory of other processes mapped into kernel space, via Meltdown only). KPTI doesn't forbid a thread in a process from reading a memory which is, from the operating system point of view, available for the whole process to read, which is the case of passwords and cookies stored in the same browser process a JS sandbox runs in.

Also, to be one hundred per cent accurate, you've asked if "similar mitigations" (to JS VM ones) are needed in VMs for other languages. Please note that a contemporary in-browser JS VM already features an overall well-designed sandbox which has limited access to filesystem, IPC, assembly language, and other system resources. In case your VM (e.g. a V8 JS VM which is shipped with Node.js platform) has more permissions or abilities than an in-browser JS VM has, it may require not similar, but further and more strict mitigations.

As of January, 14, 2018, this is in theory; but your question is also theoretical.


When you can configure the ISP router to run in bridge mode and connect a second router behind the ISP one, you can manage all your port forwarding rules yourself.

Make sure that DHCP is disabled on the ISP router and enabled on your own router. This might be done automatically when the ISP router is put in bridge mode.

  Is this a good or bad idea?

This depends on how you configure your own router. Exposing the administrative interface over the internet for example is something you probably don't want to do. You are required to manage your own router, check for firmware updates etc.

Additionally, it might (or might not) violate your ISP's policies. Your "friend" most likely is violating his employer's policies.

Since your ISP limits you in exposing external services, you might want to consider changing to another ISP that does not limit you.


Saving Authentication Tokens to Third-Party Websites

The quick answer is that storing the plaintext authorization tokens in a database is not a problem but there are some other aspects that are more critical in keeping the tokens (and use of them) safe.

Make sure the oauth_consumer_key (app key) and oauth_token (authorization token) are never sent to or stored at the clients side (the users browser, phone, etc.). This means that the requests to the Service provider (Flickr) must always be done from a server that has access to the database and then the data received from the Service provider data can be forwarded to the client. If you store the key and token at the users side, then they will be able to impersonate your application and access restricted data.

To secure the key and tokens during the request from your server to Flickr, do the request as a POST over HTTPS. This way an eavesdropper cannot get hands on your tokens while they are on their way to Flickr.

Secure your database, not by encrypting the tokens, but by making sure that any unauthorized access to the database is not possible. If your database gets compromised (eg. SQL injection, any other injection) then the earlier measures don't really have any effect. This is a good thing to do in general, and I'd advice it over you encrypting the tokens in the database.

Sources: OAUTH v1.0 and the Flickr authentication API.


Sending Syslog/SNMP information over the internet using standard UDP port 514

You have a few options:

First one that comes to mind is creating an SSH tunnel from your Windows Server to your Syslog Server and sending your syslogs to localhost:1514 which would tunnel to logserver:514. This would encrypt your Syslog data in an SSH tunnel. You can do this several ways, like a batch script on startup to invoke PuTTy, like this http://howto.ccs.neu.edu/howto/windows/ssh-port-tunneling-with-putty/
Secondly, which is what I do, is use a tool like Logstash to receive syslogs and read log files locally, and set up an output over HTTPS. Logstash requires Java Runtime, but is very powerful, uses very little resources, and is extremely customizable.
You can pay for syslog-ng professional which will do TCP over 514 and you can apply TLS/SSL to it.


What is the risk of my VPN traffic routing through China?

In the case of VPNs, you shouldn't have to worry about whether or not it goes through China. What you should worry more about is the integrity and model of the VPN service you're using. If the encryption is secured, it should not matter what route your traffic takes.

Here's a simple model of a VPN (MITM = man in the middle)

You ----- VPN
      ^
     MITM

If the VPN service is secured, no one as the MITM should be able to read your data, Chinese or not. It should be the same no matter what route your traffic takes: everything between you and the VPN server is encrypted.

Even if the host/server of your VPN is in China, the main concern should be "Can I trust this VPN provider?" rather than "Can I trust China?". If the government mandates the VPN provider to give them your data, that's going to depend on the provider to not give out your data.

TL;DR: It shouldn't matter what's between you and the VPN. It should be encrypted and no one should be able to read it.


Can Google deduce the visited URLs from Safe Browsing reports?

You are right that in order to mark a hash as belonging to a malicious URL, Google needs to have visited that URL in the past and have decided that it was malicious.
It would be quite reasonable for them to keep the URLs they have labelled as malicious. Indeed if they have any sense, they will, because the more hashes they accumulate, the more URLs will turn out to have the same hash by accident. Suppose the hash list grew to have a million hashes. Then any URL at all would have a 1 in 4,000 chance of having a “malicious” hash. Either Google will have to re-scan the “malicious” sites from time to time or they will have to change to, say, a 40-bit hash. Either way they will need the original URL.
So for you, there are three possibilities.

Your URL's 32-bit hash is not in Google's list. In that case Google knows nothing about what URL you visited.
Or your URL's 32-bit hash is in Google's list. In that case Google can infer that your URL is equal to their malicious one.

a. They may be right.
b. They may be wrong, and your URL may be something quite different.

Google has no way (based on the description you quoted) of distinguishing between 2a and 2b.
But to summarise, Google can't know anything directly about your URL, but if (and only if) it appears, from checking the hash, to be malicious, they know which malicious URL they think it is.


For standard applications I usually raise this as a "low" priority finding, mainly as if an attacker has compromised an account, it can be a useful restriction to have a user only able to maintain a single session and log out old sessions when a new one is started, that way the attacker gets kicked out the next time the user logs in.

In this scenario the attacker would need to be signed into the domain account of the user in order to have access to their session, so really the control should be placed at the domain level (e.g. stop users having multiple concurrent domain logins) if that's desirable/possible in the context of your organisation

So I'd say that the recommendation doesn't really apply to the application that you're developing, as the application doesn't really have control over that aspect of authentication.


Proper cryptographic hash functions are all-or-nothing: you either get the exact correct input, to the last bit, or you get nothing. No patterns, no partial solving, no Mastermind-like cracking. That's why it is called brute force: there is no finesse whatsoever in password cracking.

Being able to solve passwords "partially" only happens in Hollywood movies, or in cases of blatant incompetence.


From the documentation:

  CIPHER LIST FORMAT...
  It can consist of a single cipher suite such as RC4-SHA....
  Lists of cipher suites can be combined in a single cipher string using the + character. This is used as a logical and operation. For example SHA1+DES represents all cipher suites containing the SHA1 and the DES algorithms.

Thus, RC4-SHA is the RC4-SHA cipher, also known as TLS_RSA_WITH_RC4_128_SHA:

$ openssl ciphers -V 'RC4-SHA'
  0x00,0x05 - RC4-SHA                 SSLv3 Kx=RSA      Au=RSA  Enc=RC4(128)  Mac=SHA1

RC4+SHA instead contains all ciphers which use RC4 encryption with SHA1 as MAC, i.e.

$ openssl ciphers -V 'SHA+RC4'
  0xC0,0x11 - ECDHE-RSA-RC4-SHA       SSLv3 Kx=ECDH     Au=RSA  Enc=RC4(128)  Mac=SHA1
  0xC0,0x07 - ECDHE-ECDSA-RC4-SHA     SSLv3 Kx=ECDH     Au=ECDSA Enc=RC4(128)  Mac=SHA1
  0xC0,0x16 - AECDH-RC4-SHA           SSLv3 Kx=ECDH     Au=None Enc=RC4(128)  Mac=SHA1
  0xC0,0x0C - ECDH-RSA-RC4-SHA        SSLv3 Kx=ECDH/RSA Au=ECDH Enc=RC4(128)  Mac=SHA1
  0xC0,0x02 - ECDH-ECDSA-RC4-SHA      SSLv3 Kx=ECDH/ECDSA Au=ECDH Enc=RC4(128)  Mac=SHA1
  0x00,0x05 - RC4-SHA                 SSLv3 Kx=RSA      Au=RSA  Enc=RC4(128)  Mac=SHA1
  0x00,0x8A - PSK-RC4-SHA             SSLv3 Kx=PSK      Au=PSK  Enc=RC4(128)  Mac=SHA1


Basis Authentication Protocol: a concrete attack

There is no proof that the message was intended for B. So, intruder I can intercept the message signed by A and redirect it to B, authenticating I as A. But what is a harmful attack? For example in a bank-client interaction scenario?

If I understand you correctly, you've just described the first part of a Man In The Middle (MITM) attack.


Another domain is using our web app's IP address. How to prevent it?

Our web application is being mimicked by another domain ...

The domain in question is configured to resolve to the same IP address as yours. That's why it looks like they mimic you when in fact it is simply the same physical server, only accessed by another name.

But when using the URL from your question one gets a security warning in the browser: the certificate is for nrnsewa.com which does not match the name in the URL www.djjpl.com.sg. Since this  warning will scare away most visitors I doubt that this is an attack but believe that it is simply a misconfiguration for www.djjpl.com.sg.

  How can we prevent it?

You have no control what others configure for their domain. This includes misconfigurations where they accidentally configure the wrong IP address for their site in DNS. This includes also that they don't update their records if they no longer use a domain which means it might point to IP addresses which are used by others in the mean time. Anybody could configure their domain to point to an arbitrary IP address (including yours), both deliberately and by accident.

But what you can do is refuse access to your site or show an error when the domain name in the TLS handshake (i.e. HTTPS-URL's) or the HTTP Host header do not match your site. How this is done depends on the specific server implementation you have. See for example How can I block requests with the wrong Host header set?. And even if you don't care about such misconfigurations, enforcing the correct Host header is still recommended since it prevents some attacks like DNS rebinding.


Nexus 7 (Or any other good android tablets) For pen testing

Small update: Kali Linux NetHunter was released last month and appears to be the de-facto standard for pen testing from an Android platform

Because of the support for recompilation of drivers that are known to support monitor-mode and/or frame injection, it appears that testers are sticking to the Broadcom chipsets (BCM). bcm4xxx are especially popular on Android devices, especially and notably Samsung.

Working out of the box, you have the Samsung Galaxy S II and the Nexus One. Recently added out of the box support for the HTC EVO 4G is also currently available. Using CMC or similar technique (AOSP would just be too annoying), one could add in the drivers to other devices with similar BCM chipset WiFi boards.

Ideally, you'd use a Samsung Galaxy Note for the CMC conversion of the driver over to at least monitor-mode standards. Theoretically, wash(1) should work in both passive and active modes, but the active WPS attack in reaver would likely require some additional driver modifications.

However, with Complete Linux Installer (on a rooted device) or Ubuntu noroot, one could install BackTrack 5r3 with aircrack-gui-m4 and Johnny (or additionally, even Reaver Pro if the reaver bits are working) for excellent X11 GUIs to control attacks.

Outside of WiFi Analyzer, Fing, Shark, and zAnti -- I would definitely add in X-plore and androidVNC. Some apps are better done without X11, and some GUIs from X11 simply are not yet replaceable via the Android SDK, Play Store, or alternate app market.

My suggestion would be to wait for the Samsung Galaxy Note 2 to arrive to your US carrier (note that there is an international version already available, certainly preferred over the US versions for a variety of reasons) and purchase then, helping along with the development of that platform for penetration-testing specifications.

I have personally added the vulscan NSE script to zAnti to make it that much more powerful. Along with a BackTrack 5r3 install via Complete Linux Installer, it would be possible to run Metasploit (any web edition such as Community or Express) on the web ports and access it via an Android browser, in addition to running Nessus and accessing it with the Android SDK app.