Google's Certificate Fingerprint doesn't match with the Fingerprints in the Chrome's "net-internals" configurations

The four hash values you see are SPKI hashes. While the fingerprint you see when looking at the certificate is computed over the whole certificate the SPKI hash is only computed over the SubjectPublicKeyInfo, i.e. the public key contained in the certificate. See Mozilla:HPKP for more details including ways to compute the SPKI hash using common tools.

Apart from that these SPKI hashes do not necessarily specify the leaf certificate (i.e. the one you were looking at). Instead at least one of the SPKI hashes for a site should match one of the certificates in the certificate chain, i.e. from leaf up to and including the locally trusted root certificate. This matches the behavior of the HPKP header which is described in RFC 7469 as follows:

  ... compute the SPKI Fingerprints for each certificate in the Pinned Host's validated certificate chain ... check that the set of these SPKI
     Fingerprints intersects the set of SPKI Fingerprints in that Pinned
     Host's Pinning Metadata

To manually do the checks one might export every certificate from the browser, compute the SPKI hash (see first link on how to do this) and then check if it is in the list of preloaded SPKI hashes. For the connection I get to www.google.com I get the following chain (note that I get a different leaf certificate):

[0] www.google.com
cert fingerprint: 27:4C:3B:05:9F:30:5C:C3:C7:EE:23:98:E5:33:21:EE:56:34:E0:40:96:09:1E:87:BE:F0:9D:AF:A7:44:39:12
SPKI hash: He1hxIXPpsnamgIS9IH1HC45P2yj45Py1fi0/JI6JBo=

[1] Google Internet Authority G3
cert fingerprint: BE:0C:CD:54:D4:CE:CD:A1:BD:5E:5D:9E:CC:85:A0:4C:2C:1F:93:A5:22:0D:77:FD:E8:8F:E9:AD:08:1F:64:1B
SPKI hash: f8NnEFZxQ4ExFOhSN7EiFWtiudZQVD2oY60uauV/n78=

[builtin] GlobalSign Root CA - R2
cert fingerprint: CA:42:DD:41:74:5F:D0:B8:1E:B9:02:36:2C:F9:D8:BF:71:9D:A1:BD:1B:1E:FC:94:6F:5B:4C:99:F4:2C:1B:9E
SPKI hash: iie1VXtL7HzAMF+/PVPR9xzT80kQxdZeJ+zduCB3uj0=

As you can see, the last SPKI hash from the builtin root CA intersects with the preloaded SPKI hashes which means that the validation was successful.

If you want to know what the other SPKI hashes are for you might have a look at the source code for Chromium where it shows the following definition for the PIN set used for the Google domains:

  "name": "google",
  "static_spki_hashes": [
    "GoogleBackup2048",
    "GoogleG2",
    "GeoTrustGlobal",
    "GlobalSignRootCA_R2"
  ],

The last item GlobalSignRootCA_R2 is the one found in the current chain.


Does crypto shredding count as deletion in regards to CCPA?

The CCPA statute doesn't provide a technical definition of "delete".  This means that until a court case interprets the law otherwise, you can take whatever actions you deem technically sufficient to render the data "deleted".  What would be important is that, if you were challenged in court for not deleting a client's data, you could convince a judge that the data was deleted, destroyed, or somehow rendered unrecoverable.

What this typically means in practice is that you would need to consult with your organization's attorney, CCPA compliance team, or risk management team about your proposed data deletion solution.

That said, any legal defense would be on much firmer ground if you employed an existing industry or national standard for data destruction.  Consider following something like NIST SP 880-88, which is a national standard for media destruction.  It defines three levels of media sanitization: clear, purged and destroyed.  No rational interpretation of California law would require you to physically destroy a hard disk that once held a person's data, so you can probably eliminate "destroyed" as a path you'd need to follow.  To clear means to remove the data using overwriting techniques, but is not necessarily defense against a forensic laboratory recovery of the data.  To purge is to render the data unreadable by an attacker using state-of-the-art laboratory techniques.  And they specifically cover Cryptographic Erase as a valid purge technique, when certain factors exist.

Just be aware that Cryptographic Erase is actually a very complex solution to achieve in practice.  It involves maintaining separate keys for each block or category of stuff you wish to destroy.  That's pretty easy when it's a one-key-per-hard-disk-controller relationship to be used for purging an SSD or HD of all its data, but a lot harder when you're only trying to delete a few rows from a database.  You certainly could maintain one key per customer, but that might be a lot of keys to manage, and require an expensive and complex key management system.


Usefulness of Server's Work Load given Timing Attack Resistance of Responses

If an attacker was attempting a DoS on a server, measuring the load could provide information regarding the success of a DoS as well as help the attacker determine how much more resources are required to further the attack.

This could be helpful if resources are not freely available. Perhaps the resources are busy doing other things and will be costly to change what they are doing. Another example may be if you are purchasing time on a botnet for a DDoS. There resources cost money.


If you don't have a modem attached to a phone line then the "dialer" is harmless, but nothing tells you that it's only a dialer and not a general-purpose rootkit/remote administration tool.

Note that mobile broadband cards (either as external USB devices or built-in) still appear as a modem and most of them can do phone calls, so if you have mobile broadband then it may still use your mobile subscription to call the number (which may be even worse because calls from mobile are usually more expensive).

Better safe than sorry, so my advice is to follow this guide and reinstall.


it is possible to make some wifi router out of service without have the connection password?

You can deauthenticate users.
With aireplay-ng this makes users disassociate with the router denying them the service

This with the option -0
So

Aireplay-ng
    -0 [how many packets you wannt to send] \
    -a [mac of ap] \
    -c [mac of client you want to deauthenticate] \
    [interface]

If you are associated to the network you could arp-spoof the clients to belive you are the router and just do whatever you want with the traffic


It is not illegal here in the US.

I would be wary of seeking legal advise on the internet, especially without giving a specific location. Laws change city to city as they do country to country.


Pitfalls of using SELinux for LAMP servers

If you've regression tested everything and not encountered any unsurmountable issues, then great, however my experience is the opposite of TorstenS - I think it results in a net decrease in the security of your system except in the specific scenarios (and "LAMP server" is unlikely to fall into that category) listed in the linked post.

To summarize - the complexity, opaque abstraction and poor documentation make it very difficult to understand the implementation and to adapt it to specific purposes. There is little evidence that even an expertly configured installation is more secure than a system not enforcing a policy. While intrinsically it is unlikely to increase your attack surface, it is likely that solving the functionality an performance impacts it introduces (i.e. compromising the off-the-shelf policy supplied by your vendor) will undermine the overall security of the system in ways you don't understand.


Does the use of a smartphone's Secure Element really offer security benefits to a banking app?

So both of your scenarios rely on the attacker having root access to the phone. In security, it's generally considered that once an attacker has root access, it's game over. That said, there are still interesting things to be said about your question.

You asked:

  Is there a situation where the secure element does offer a clear security benefit to this banking app, making it reasonable to mandate it?

Being a little bit cheeky: Yes, normal use-cases where the user has a password / pin lock, and the attacker does not have root access.

Going a little more in-depth:

When you say "reasonable to mandate it" I assume you mean vs offering the same functionality to users with non-Secure Element devices by storing the key in software? A few things come to mind:

On Android > 6.0 (and I bevieve iOS) the crypto happens inside the Secure Element / Secure Enclave, so the private key never enters userland, so it is immune to potential vulnerabilities / sloppy coding in the banking app itself or the software crypto libraries they use. (generally a good practice).
Because the private keys never leaves the Secure Element's keystore, it is impossible to extract them from the device and run the spoof from a server; you need to do it from the physical device. If the owner discovers that the device has been stolen, they can do a remote wipe, which will clear the private keys, attack over.
If the keystore is password protected, then in the case of a software keystore, you can extract the file to a server and brute-force the password to your heart's content. In the case of a Secure Element, after some number of brute-force attempts, they can wipe the keys.
While still a bit experimental, Android and iOS are starting to offer neat access control mechanisms on when the hardware key store will unlock the keys and perform crypto for you. For example, you can program your app to request crypto from the SE in the following way "Sign this data, but only if the device was unlocked using password, fingerprint, or PIN, and if the device was unlocked more than 5 minutes ago, re-prompt them for their login first". That level of control is fundamentally impossible with software-based keys.

None of those things are 100% foolproof against an attacker with root access to the device, but I think they show that a hardware keystore / crypto module does add some value. My professional opinion is that it's a defensible choice for a banking app to allow you to bypass a physical token generator only if your device has a Secure Element.

[Disclaimer: the Android Secure Element underwent a major overhaul in Android 6.0, so what I said above does not apply to Android < 6.0 which did not do any crypto in the SE and did hand the private keys back to userland.]


Protect our payroll data from a legal and moral obligation

You should take the usual precautions to secure any important server.

1) Properly configure a firewall to have a deny by default policy and only whitelist approved traffic.

2) Proper ACL keeping in mind the principle of the least privileged.

3) Properly authenticating the application that accesses the server - this might mean a good highly random password with enough entropy, authenticating against an AAA server or even certificates depending on the scale of your setup.

3) Encrypt the database - do not count on an old legacy system making it difficult for a malicious attacker to read your database.

4) Log all activities - proper accounting makes it much easier to track unintended changes to the system.

Depending on the type of information you hold, you might need to meet certain compliance schemes. I do not have much idea about this point though, you might want to check with a local audit company for more information.


My personal phone sent a text message that I did not send

If you still have service to your phone, it's unlikely to be a SIM swap attack. Generally, one of the consequences of a SIM swap is that all the services provisioned on your phone (including your phone number) are transferred to the attacker's phone, by the exact same process as those services would be transferred to your new phone when you upgrade. This is the whole point of a SIM swap, because the attacker is trying to intercept any calls or texts which are generated by a multifactor authentication (MFA) scheme to use to impersonate you to that service. More at https://en.wikipedia.org/wiki/SIM_swap_scam.

It's possible, but highly unlikely (unless you are a high-value target of a nation-state-level threat -- and you would know if that were the case), that your SIM could be cloned rather than swapped. Cloning is illegal in the US, and in any case is detectable by carriers who have an incentive to stop such arrangements because they can be used for billing fraud. More at https://en.wikipedia.org/wiki/Phone_cloning.

All of this means that it is likely that it was simply a spoof.


What are the risks in using a VPN tunnel

If the VPN is untrustworthy they can read your traffic instead of your ISP. Whether that's an improvement or not is up to you really! Can't say I've heard of the one you linked, and this isn't the place for product recommendations, but have a shop around for a trustworthy VPN provider. Or alternatively pick up a cheap VPS (a server you can run yourself) and follow a guide to set up a VPN service on there, and have your own private one.


Client id and secret as part of query parameter

How do you define ‘secure’? It’s certainly not as nice as sending credentials as headers, but Z.T. is right that they can’t be accessed in a URL using TLS. That being said, also as Z.T. alluded to, the fact they’re being sent in a URL means that it’s also likely (or at least much more likely) they’re being logged. Credentials being logged both poses its own set of risks and implies the possibilities of others.

So to answer your question of whether it’s secure to use credentials in URLs - really the answer to that depends on what your threat model looks like. My guess, based on what you’ve described, is that it’s maybe not extremely risky but also maybe not great. (Caveat emptor that that’s just a guess though.)


SQL Injection - Automating the fingerprinting of the DBMS

If you like to automate fingerprinting i recommend using more than just one indicator, because sometimes it happens to be a little tricky...

Even i hate those timing attacks they are sometimes quite useful... Here another hint on different sql dialects...

(MSSQL)   http://www.example.com/abc.php?id=1; waitfor delay '0:0:10'--

(MySQL)   http://www.example.com/abc.php?id=1; if 1=1 BENCHMARK(1000000000,MD5(1))

(Postgre) http://www.example.com/abc.php?id=1; select pg_sleep(10);


Appending a secret (pepper) to Argon2 password hashes

Argon2 actually allows a pepper in the algorithm itself, called the secret. This would be the ideal way to use a pepper, unfortunately most language bindings I've looked at don't expose this parameter (of the bindings listed on GitHub only 2 of them specifically mention supporting keyed hashing).

If the secret parameter can't be used, argon2(hmac(pepper, password)) is a reasonable alternative. argon2 can be applied outside hmac for simplicity, as the way it's generally used it'll give you an output that includes an encoding of the salt and options used. Using hmac outside argon2 should be comparable for security, but then you'd need to keep track of the Argon2 parameters yourself.

As for the spec seeming to indicate that a pepper isn't necessary, I assume you're referring to this:

  A trivial solution for password hashing is a keyed hash function such as
  HMAC. If the protocol designer prefers hashing without secret keys to avoid all the problems with key generation, storage, and update, then he has few alternatives: the generic mode PBKDF2, the Blowfish-based bcrypt, and
  scrypt.

The way I read it, what that's saying is that a keyed hash is actually the best way to hash passwords, so long as you protect the key really well (such as using an HSM). The problem is, protecting the key is difficult (HSMs cost money, supporting a pepper with an HSM takes development time), so slow hashes like scrypt, bcrypt, and Argon2 are used instead.

What it's not saying is that using a keyed hash in addition to Argon2 is a bad idea. Even if you can't protect the key with an HSM, it can still be worthwhile if it's better protected than the password hashes. The worst passwords will always be cracked no matter how high you set the cost (and your users' patience gives you a low upper limit); a pepper can prevent that.


Conflicting security messages about "chrome://settings" page; is it secure or not?

Yes, your settings page is secure. What you're seeing is just an inconsistency on Chrome's side.

In the devtools, only valid HTTPS connections are labeled "secure". Other documents, including local files and settings pages, are shown as "not secure", even if they don't ever go through a network. The notion of a "secure connection" just doesn't apply to local resources. (A settings page is local, too.)

Why? Because the label is based on a site's SecurityState which is set to "neutral" for plain HTTP sites, local files and settings pages alike. And a "neutral" security state is verbalized as "not secure":

const summaryExplanationStrings = {
  'unknown': Common.UIString('The security of this page is unknown.'),
  'insecure': Common.UIString('This page is not secure (broken HTTPS).'),
  'neutral': Common.UIString('This page is not secure.'),
  'secure': Common.UIString('This page is secure (valid HTTPS).')
};

(Source)

In the address bar, however, Chrome has a special label for viewing an internal page:

<message name="IDS_PAGE_INFO_INTERNAL_PAGE" desc="Message to display in the page
 info bubble when the page you are on is a chrome:// page or about:something.">
    You are viewing a secure Google Chrome page.
</message>

(Source)

Hence, the texts differ. Ultimately, the security indicators in the address bar should be your preferred means of verification. In other places, such as the devtools, the UI may be not as clear.


What is the best way to show a (long) number for comparison?

Display one number directly below the other.  Slowly move the two numbers on top of one another until they overlap.  If they perfectly co-inside, they're the same number.

For bonus points, make one number in yellow, another in blue.  Combined they make green.


There are a couple issues here.

First off, I am assuming you are talking about an HTTP GET request. These requests are sent once a connection is established, so you would need to have a port open to see this.

With that said, it doesn't matter what port you have open or what service is running on that  port. The GET might fail, but it is surely possible for someone to send it to any listening socket.

You mentioned that this is your home computer. Most home computers are behind a router using NAT. If this was the case, you would need to explicitly forward external ports to your internal IP in order for an outside connection to be established with your internal address.

So in short, yes its possible. It's also possible that this is a false positive or misinterpretation. If you want to know more, you need to provide more details.


What does it mean by the 'Hash of a malware'?

A hash of a file, means compute the cryptographic checksum of the file.  In a linux/unix operating system, you'd type md5sum name_of_file at the prompt.  Assuming you have GNU coreutils or their equivalent with the md5sum file, like:

# md5sum name_of_file
d41d8cd98f00b204e9800998ecf8427e  name_of_file

where d41d8cd98f00b204e9800998ecf8427e is the MD5 hash of the file name_of_file.

You are expected to have a variety of malware binaries that you can hash yourself, or at least have obtained the hashes of the malware binaries from some other source.


Can we restrict cipher suites using server certificate?

A TLS cipher consists of a part defining the authentication of the certificate (i.e. ECDSA, RSA...), a part defining the key exchange (ECDHE, DHE...) and a part about the kind of symmetric encryption and the associated HMAC, i.e. RC4+SHA1, AES128+SHA256 etc.

From these parts only the authentication part depends on the type of certificate and everything else is independent. This means that you are not able to restrict the use of specific symmetric encryption within the certificate, like denying RC4. This can only be done by configuring either client or server to not include such ciphers in their SSL configuration.


Did I just give away my credentials by trying to connect to the wrong VPN?

No. OpenVPN is constructed in a way that the client and server will mutually authenticate each other, so the credentials is never sent over the wire.

Also, in addition to this, the validation is failed due to mismatch between the imported CA and the server's certificate. So no authentication happened.

Basically, the server sends you some random data, that you sign with your client key, and send along with your certificate to the server. The certificate itself, without the key, cannot be used to login on the VPN as you, and isn't sensitive.

If the Connection succeeded, it just means that AirVPN both owns airserver.org and airservers.com


Login info over https and controled network

The rule is that you cannot protect a system against its administrator.

If the security team has installed a Deep Packet Inspection on the firewall, and an associated certificate on your client machine, you have full encryption between the client and the firewall, full encryption between the firewall and the server, but everything can be consulted as plain text in the firewall.

The implementation principle is that the firewall uses its master certificate to pretend being your server with a forged certificate. As your client trusts the master certificate of the firewall (the key is here) it accepts to establish the connection. Then the firewall opens another connection to the server and just passes all packets after inspecting them.


SAML2 vs. OAuth - What are some reasonable relationships?

Bridging the SAML and OAuth 2.0 frameworks is a well understood problem. The following stack of IETF specs provides a standard solution:

If you look at the core OAuth 2.0 spec (RFC 6749) and its token endpoint definition - this is basically an OAuth server endpoint which returns an access token in exchange for a "grant" -- an open-ended concept of something deemed appropriate to grant the client app the issue of an access token. In the typical OAuth scenario this is an authorisation code signifying that the user has been previously authenticated and given their consent. But the grant could also be something else.
There is a further IETF spec called draft-ietf-oauth-assertions-16 that builds on the core RFC 6749 standard which says that the grant can also be an assertion (a signed proof of something) and defines the necessary token request parameters for that.
Finally, there is draft-ietf-oauth-saml2-bearer-20, which specifies how this assertion can be a SAML 2.0 Bearer Assertion.

This standard mechanism for converting a SAML assertion into an OAuth 2.0 access token is essentially all that is needed to bridge the two frameworks.

To ensure removal of users is properly reflected by the authorisation systems there are two approaches, which can be combined:

Make the OAuth 2.0 access tokens short lived. This will force the client to repeat the authorisation process when the token expires, and if the user no longer exists authentication will fail and no grant (SAML assertion) will be issued.
Provide an API for revoking issued OAuth 2.0 access tokens, see RFC 7009 for details.


Is this Perl database connection vulnerable to SQL Injection

After recreating the website locally and reviewing the docs
Yes
This Perl program is vulnerable to SQL Injection.

However this depends on the DBI driver, and could only reproduce this with MySQL

There are 2 flaws with this in $dbh->quote(param('paramater'))

You see, param is context-sensitive. In scalar context, if the parameter has a single value (name=foo), it returns that value, and if the parameter has multiple values (name=foo&name=bar) it returns an arrayref.

From the SO link, the problem with directly calling param() is that it can return an array

As a special case, the standard numeric types are optimized to return $value without calling type_info.

From the DBI docs. Calling quote as a list with SQL_INTEGER as the second parameter, will return an unquoted value.

Since SQL_INTEGER == 4 All it took was this python script:
def vuln(url):
    params={"username": "valid_username", "password": ["'lol' or 1", 4]}
    print(requests.post(url, data=params).text)


How to detect infected machines on my wifi?

You say the ISP has detected large volumes of spam. So the easiest way to find the offending system is to monitor the outgoing line for connections to port 25. If you find a host that does a lot of those, then you've probably found the infected machine.

To do this, you would need to sniff right before or after the last router. You'll need cooperation from the landlord I'm afraid. Depending on the gear in front of the internet trunk, you could put a linux box in between with two network interfaces, that forwards and logs. You could also find other malware trying to spread.

Beware however, IANAL, perhaps you're invading others' privacy of you start poking around in their traffic. If you keep it at netflow data (src ip, dst ip, src port, dst port, time, bytes) however, you should be ok. And that should point out the spammer.


Simply put, unless you're talking about WPA2-Enterprise with EAP, there's no verification.  Wifi networks are identified by SSID alone, so if you rename your home wifi network to "attwifi" and remove the password, chances are you'll get quite a few strangers' devices automatically connecting to it.  This would be called a rogue access point.

Of course, if the app-to-cloud communication is encrypted (with SSL/TLS), then it really wouldn't matter if the app sends information through a rogue access point.  It's the unencrypted communication that would pose a security risk.

Edit:
I believe recent developments have potentially made it possible to authenticate hotspots using EAP-TLS, though I'm not very familiar with how exactly this procedure works, so perhaps someone else can elaborate.  I did find the following on Wikipedia:

  On 22 August 2012 hostapd (and wpa_supplicant) added support in its
  Git repository for an UNAUTH-TLS vendor-specific EAP type (using the
  hostapd/wpa_supplicant project RFC 5612 Private Enterprise Number),[7]
  and on 25 February 2014 added support for the WFA-UNAUTH-TLS
  vendor-specific EAP type (using the Wi-Fi Alliance Private Enterprise
  Number),[8][9] which only do server authentication. This would allow
  for situations much like HTTPS, where a wireless hotspot allows free
  access and does not authenticate station clients but station clients
  wish to use encryption (IEEE 802.11i-2004 i.e. WPA2) and potentially
  authenticate the wireless hotspot. There have also been proposals to
  use IEEE 802.11u for access points to signal that they allow EAP-TLS
  using only server-side authentication, using the standard EAP-TLS IETF
  type instead of a vendor-specific EAP type.[10]

Source


Why are SQL servers not attacked as frequently as ssh servers?

Because:

1) Most RDBMS (including MySQL) don't instrinsically support client connections or access to a shell to start a new client (limiting malware's ability to spread)

2) Most people don't expose their DBMS on the internet


Message Encryption vs Digital Signature for authentication

Yes, well-observed. In fact this is used in real-world crypto systems:

The Kerberos protocol that underpins all Windows authentication does almost exactly what you're suggesting (source: wikipedia.org/Kerberos_(protocol).

  Client Authentication

  The client sends a cleartext message of the user ID to the AS (Authentication Server) requesting services on behalf of the user. (Note: Neither the secret key nor the password is sent to the AS.) The AS generates the secret key by hashing the password of the user found at the database (e.g., Active Directory in Windows Server).
  The AS checks to see if the client is in its database. If it is, the AS sends back the following two messages to the client:

  Message A: Client/TGS Session Key encrypted using the secret key of the client/user.
  Message B: Ticket-Granting-Ticket (TGT, which includes the client ID, client network address, ticket validity period, and the client/TGS session key) encrypted using the secret key of the TGS.

  Once the client receives messages A and B, it attempts to decrypt message A with the secret key generated from the password entered by the user. If the user entered password does not match the password in the AS database, the client's secret key will be different and thus unable to decrypt message A. With a valid password and secret key the client decrypts message A to obtain the Client/TGS Session Key.

As you point out, this is as a valid authentication mechanism which takes less computation than digital signature, but it requires a pre-shared secret. This is a BIG BUT in a lot of situations.

For example, I want to create a new account at mybank.com, which I want to do over https. My browser has never been there before, so I don't have a pre-shared secret with the mybank.com server. Part of the https handshake is having the server authenticate itself to the client (prove that it is infact mybank.com, and not a man-in-the-middle), which is impossible to do using only symmetric crypto and no pre-shared secret.

It is for situations like this that Public-Key cryptography is king.


What do we look for? -- A Security Expert. To Hire.

That is a 100% serious answer -- If you are asking this question you need someone in house who can answer it.  Selling a "security monitoring service" without an expert on staff is a Bad Idea. You will make a mistake, it may result in a client being compromised, and you won't have the expertise on hand to deal with it.  All of that makes you look bad, and much of it can be avoided by having someone with decent security knowledge on staff.
(Also expect that your customers will need their security assessments explained to them -- It's hard to do that if you don't have a handle on the technology used to do the assessing.)

After you've found your security expert you can proceed with deciding what to look at and how to approach security assessments and management.

The simplest and easiest thing to do is not look at anything and just make it your policy that all available patches are automatically applied to all managed machines.
(For suitably broad definitions of "simplest" and "easiest": You need some way of pushing out these updates.  WSUS or a commercial solution like Citadel/Hercules is a common solution on Windows, and Puppet or RedHat Network satellite servers are pretty common in the Linux world.)

This is a shotgun approach: Absent any other information you're just installing every patch available and hoping to plug some holes.  It works for a lot of environments, but it can also introduce mysterious breakage when you apply a patch that doesn't fix any particular vulnerability for you, but changes your system in a way that upsets the local software.

The rest of my answer looks at security assessment in two phases -- Outside-In and Inside-Out.  It is by no means comprehensive, but should give you some good ideas.

Outside-In assessments

The first big item in Outside-In assessments is to start proactively looking at your hosts for potential problems.

Tenable Networks Nessus vulnerability scanner is the flagship product in this space, with OpenVAS being a popular open-source alternative.
These programs scan hosts looking for vulnerable services as identified by "signature scans" -- Sometimes they will issue a false positive, but often they spot real problems that you may not be aware of.  If run regularly they can help you target specific patches which need to be installed on your systems, as well as allowing you to determine compliance with the patching policy (If everyone was supposed to be on FooServer 1.2.3 as of last month and someone is still running 1.2.0 there's a problem that needs to be addressed).

These tools basically automate what "hackers" have done since the dawn of hacking:

The other major "Outside-In" tool is a network IDS (and/or IPS) -- Something that sits on your network and looks for "things that just don't seem right".
Snort(Snort IDS) is the flagship here, and widely regarded as a pretty decent product.  A good network monitoring system can also help you catch "interesting" traffic patterns so you can look further into them to see what's going on.

A good IDS/IPS may not prevent a system from being compromised, but if configured properly they can isolate machines behaving suspiciously and prevent them from being used to compromise other systems on your network.  The ideal configuration for your situation is very much dependent on your environment, and something the aforementioned expert could help with.

Inside-Out Assessments

The first step in inside-out assessments is configuring systems for security - the absolute basics of making sure unnecessary services are stopped, default passwords changed, SSH switched to key-only logins, Configuring Fail2Ban, etc.
Any competent sysadmin should do this as rote habit, so I won't go into any real detail.

The next steps can really be taken in any order, but they are all more reactive (notifying you that a breach may have occurred) than proactive:

Log Analysis and Centralized Logging
Most Linux systems ship with LogWatch these days -- it has its problems, but it can be helpful on occasion.  Similar concepts exist for Windows networks: something to let you know when the system logs an "unusual" event.
Ideally you would run this on a centralized, secured logging server (so that if a machine is compromised and the logs erased you still have a record).
Checksum and Signature based system checks
A program that runs on each host and alerts you if a file that should never be changed is changed.  The flagship product here is Tripwire, but there are dozens of similar things available, and on modern Linux systems you can even hook the FAM Daemon to alert you when a file is being touched (so long as the attacker doesn't kill the daemon).
"That Doesn't Look Right" tools
This would be CHKRootKit and its ilk -- Things that look for known malware, rootkits, trojans, etc. that may have gotten onto your system.
Again, many modern systems ship with this tool or something equivalent preconfigured.
Draconian Measures
This includes things like "Kill any process which is not on this whitelist" -- They can enhance security, but the convenience (and/or usability) impact is often more than your users will bear.

Final Thoughts

Like I said, everything in this answer is just scratching the surface.  "Managed Security" is a vaguely defined term, and these are some of the more common things that are done. You will think of others -- evaluate them carefully in terms of risk, reward, and manpower in order to decide if you want to offer them (and what they should cost).

Some tips from experience:

Don't accept users' machines into the managed environment.
Make them let you build new systems from scratch, otherwise you will forever be ferreting out little problems here and there.  (In practice this almost never happens, but make sure the financial pain to the client is at least equal to the time your systems team spends trying to unravel the mess they inherit when you accept management of an existing environment someone else built)
Take away root/admin access when you assume management.
If your customers can still perform administrative tasks they may undermine everything you're doing.  Before you offer management as a service establish a clear policy for giving customers root (temporarily terminating management services), and for what has to be done before you resume management of a machine they've had root on.
(When (not if) you wind up going against tip #1 you'll use that same procedure to accept management of the disaster you're inheriting...)
Manage firewalls too
If you don't already, offer managed firewall services at the network level and limit the use of host firewalls where practical.
Having control over the firewall makes it easier to troubleshoot problems that may come up later.
Dedicate enough staff that you can perform the tasks you're committing to
Security is a full-time job.  At larger scales it becomes several full-time jobs.  Make sure you have the manpower and expertise to handle the workload you're accepting.  Scale up slowly.


Reducing password length with hash function

The "search space" has size 2256. It is not enlarged or reduced depending on whether you use hexadecimal or Base64. When you encode a 256-bit string (aka 32 bytes) in Base64, you indeed get 44 characters, but not all combinations of 44 characters (taken in an alphabet of 64) are possible. The 44th character will always be an '=' sign, and there are only 16 possible characters for the 43rd position.

Now, 2256 is huge and far (very far) beyond that which is searchable with existing or foreseeable technology. That's also beyond good science-fiction. That's even beyond bad science-fiction.

Hashing a password with a cryptographically strong hash function (and SHA-256 is indeed strong) is a valid way of "shortening" a password; indeed the PBKDF2 function (a key derivation function, often used for password hashing) begins by such a step(*). The apparent "reduction" of the space is not an issue because a space of size more than about 280 is not susceptible to exhaustive search.

Of course, this raises the question of how you will compute the hash... a password is called "password" because it is meant to be remembered by a human mind and typed by human fingers. Will you remember a hash output ?

(*) PBKDF2 is normally used with HMAC, the password being the HMAC key. In HMAC, if the key is larger than the "block size" of the internal hash function, then it is first hashed, and the resulting hash value is used as key.


SSL (TLS v1.2) - Can i offer fallback CAs when upgrading Certificates? (Java)

The solution is: do nothing.

SSL servers and clients send their certificates as chains precisely because they cannot assume that the peer will already have all needed intermediate CA certificate. The whole point of certificate chains and intermediate CA is that a "relying party" (X.509 jargon meaning here "a client or a server") can validate a chain, any chain, as long as it already has the trust anchor, which is also known as "root certificate" or "root CA". I.e. the CA which is not an intermediate CA.

For instance, assume that there is in your system a root CA which everybody knows a priori (that's what root CA are for). Then there is the "old intermediate CA" called CA1, and the "new intermediate CA" called CA2. The server previously had a certificate S1 issued by CA1, but now has a newer certificate S2 issued by CA2. A client connects. What shall the server send ? Well, the server just sends the chain CA2->S2. The client might never have seen CA2 before; it does not matter. CA2 is issued (signed) by the root, and the client knows and trusts the root, so the client can verify the signature on CA2's certificate, and thus learn that CA2 is a valid intermediate CA that the client just had not hitherto encountered. Certificate validation then proceeds with the verification of the signature on S2, by CA2. Things just work.

X.509 certificates work in a hierarchical PKI model in which actors need to be aware of root CA, and of nothing more. These certificates have been designed for the exact purpose of avoiding the problem you are envisioning, i.e. distribution of intermediate CA. Any client (or server) can dynamically build any required trust chain based on whatever certificates it has at any moment, and since certificates are chained, how they are obtained is not important. In particular they can be received by the peer, and this transfer requires no additional trust.

So as long as all servers (and client) send their certificates as part of chains which are valid at that time, validation will work.

Now if you were talking about updating a root CA, then yes, that would become tricky. Trust is transported through the signatures on certificates; but it is not created out of thin air. It has to start somewhere, and that somewhere is an a priori, intrinsic knowledge of a trust anchor. To sum up, you really don't want to change your root CA often, because it is a mess. A root is supposed to be very long-lived. And this implies using intermediate CA, because a very long-lived root is a precious thing, so you really want to keep the root CA offline, and to use it as little as possible.


Should a full disk encrypted hard drive on a live system be considered encryption at rest?

For my company at least, full-disk encryption isn't seen as adequate for 'data at rest' requirements, as on a live system the data can de accessed without providing a key or any additional authentication information. When relying on FDE, if an attacker was able to get in, at that point it's extremely easy to steal data, and do so quickly as no other knowledge is required.

We require that all data at rest be encrypted with AES (by various means) or via PGP, without regard to the use of FDE. This way just having access to a running system isn't sufficient to retrive protected data; additional knowledge (passwords, keys) are required.

We do require FDE on any system that leaves our facilities, but more to protect ancillary information that could help an attacker (email, notes, etc.) or any information stored in violation of policy.


Is it posible recover file from an encrypted home directory with a forensic tool?

Short answer: probably not. The longer answer requires some background.

To simplify heavily, a file system has two components:

The actual file data. These are simply blobs of data without names or types or anything attached to them. They are placed end-to-end but typically aligned to start at the boundaries of "blocks" of storage, so a file that's not an integer multiple of the block size will have some unused space at the end before the next file starts (this is part of why Windows' file properties window will sometimes report different values for "file size" and "size on disk").
The file system directory (sometimes called an "allocation table" or "file table" or similar). This is not the same as the "directories" (or "folders") in the file system - you can build a really primitive file system without that kind of directories being represented at all, or even existing, but you cannot avoid having the file system directory. The directory is stored at a known location and records the name (and sometimes the path) of each file, the blocks of the storage where the file's data is found, and various file metadata (size, timestamps, access permissions, etc.). Many file systems, where directories/folders also can have metadata, store records for each directory - as well as for each file - in the file system directory table. This directory also typically stores file system metadata, such as how much total free space there is, lists of blocks of free space, and so on.

When you "delete" a file, all that is actually happening (most of the time), is that the file's record is removed from the directory table (and various cleanup, like the file's blocks being added back to the list of free blocks and the file's size being added to the total free space). Critically, the file's data is unaffected (until some other file overwrites it). Thus, file undelete utilities basically do the following to try and find deleted files:

Check the start of each "unused" block for data. If there's data - that is, if it's not all null bytes - check for the "magic number" (or string) that most file types have at their beginning, which indicate what kind of file it is. (For example, all Windows executable files start with "MZ", all Zip archives - including things like .APK files - start with "PKZIP", etc.)
If it finds the start of a file format that it recognizes, the tool checks the rest of the block (and sequential ones, if needed) to verify that all the data makes sense. Determining the end of the file can be tricky; if there's a bunch of null bytes starting somewhere in a block and ending at a block boundary, then the file probably ended right before those byes, but the data between the end of the file and the block boundary might be old, partially-overwritten data instead. Files can also be "fragmented" across non-contiguous blocks, in which case the recovery tool might be able to recognize the start of the file but not the rest of it.

Essentially, the tool tries to find files that it can recognize by their data alone. This poses an obvious problem when trying to recover encrypted files: the output of any decent cipher is indistinguishable from random noise, so nothing is going to be recognizable! Depending on exactly how the file system encryption works, it might be possible to guess where files start and end, but recognizing the individual files is going to be impossible without knowing the algorithm and the key they were encrypted with.

Now, if you happen to know the key and algorithm used for at least some of the encrypted data, you could decrypt that data and see if the recovery tool can recognize it. There might be tools that can do that for encryptfs, if you supply them with the key. A run-of-the-mill tool won't cut it, though.


Change the preferred algorythm from AES to Camellia in an existing PGP key

You can look up available algorithms by running gpg --version, An example output might include:

Cipher: IDEA, 3DES, CAST5, BLOWFISH, AES, AES192, AES256, TWOFISH,
        CAMELLIA128, CAMELLIA192, CAMELLIA256

Start the edit menu using gpg --edit-key [key-id] (replacing [key-id] with your key id, and you might have to use gpg.exe again as described above). Inside, you can use showpref to list the currently set up preferences, and setpref to change them. The user interface for doing so is horrible, and you have to provide a long list of cipher, digest and compression algorithms, while the preferred ones always have to be listed first.

An article on debian-administration.org also describes this procedure, and proposes following preferences, which seem reasonable:

setpref CAMELLIA256 SHA512 SHA384 SHA256 SHA224 AES256 AES192 AES CAST5 ZLIB BZIP2 ZIP Uncompressed

(There will be a preview of the result, before you really edit the key)

Additionally for future keys, to enforce the use of CAMELLIA256, edit your gpg.conf file and add following line:

personal-cipher-preferences CAMELLIA256


wordpress server certificate does not match url

Do not do this!

Installing this certificate dramatically reduces the security of SSL for all sites (eg: your bank), not just the Wordpress sites.

If an attacker can redirect your request from a site you intend to access over SSL to any site hosted on Wordpress, your browser will not issue a warning once you have installed the certificate as described. Attacks such as DNS poisoning and MiTM are examples of attacks that would allow this redirection to occur.

Instead of trusting the certificate, you can manually approve the certificate on each access.


You are mixing up key exchange and authentication. Key exchange is done so that both parties agree on the same encryption keys. Authentication of the server is done to make sure that the client is talking to the correct server and not to some man in the middle. The RSA/ECC key in the certificate is used for authentication. In case of RSA key exchange the RSA key in the certificate is also used of the key exchange but with DHE and ECDHE key exchanges the certificate key is not used. This means you can combine ECDHE key exchange with both RSA and ECC certificates.

For the deeper details see How does SSL/TLS work?


Defense against attacks using dictionaries

Attackers often don't just use dictionaries, but also rules which permute the words in dictionaries.

For instance, a rule could be to substitute certain letters for numbers, which look the same. This would turn Password into P455w0rd.

A rule, which could apply in this case, would be to remove single letters from a word. That means just permutating the password by removing one letter or deliberately misspelling it will give you better chances, but it's not guaranteed.

To specifically answer your question: Yes, it is safer to use non-sense words than to use words in a dictionary.

However, it's not as safe as you can get. An offline password manager can generate truly random passwords for you, and will store them in an encrypted manner. This means that you never have to type in your password, except the master password to unlock the password manager.

To demonstrate this, ask yourself which password you consider safer: YunSuanLin0 or [D@,7##M]enMd*)j5fxG~KQ~?r\<DdV^?


Gradle daemon listens on all interfaces by default

If you are running a computer without a firewall that only allows access to approved services, then yes, anyone on your local network could connect to this service.

The developers of a service do not have to assume that their service is not vulnerable. They only need to assume that the people running their service have a minimum of security on the machine where it is run.

If something has an API, it typically exposes that API to the network in some way. This certainly was not always true, but it is the norm now. So the mention of an API is usually a clue that a service gets exposed.


Hide RAT in a picture link in a document?

You can't trick Facebook, because it looks into the file contents to determine its type. Moreover, pictures uploaded are automatically converted into another format.

Historically there was a related vulnerability in some versions of Windows, which simplified .jpg.exe tricks. If you included an RTL (right-to-left) character in the filename, it would be parsed right to left, so a file named as exe.something.jpg is seemingly a JPG file for the user, but it executes when clicked on.

Besides this, I don't know any other possibilities that a file with the right jpg extension would execute.


How to check if a list of domains contains any WordPress installation?

By the directory structue, like: /wp-admin, /wp-json...
You can also see through the url of images: wp-content/themes/<theme>/.
See:

    [dir] wp-admin
    [dir] wp-includes
    index.php
    license.txt
    readme.html
    wp-activate.php
    wp-blog-header.php
    wp-comments-post.php
    wp-config-sample.php
    wp-cron.php
    wp-links-opml.php
    wp-load.php
    wp-login.php
    wp-mail.php
    wp-settings.php
    wp-signup.php
    wp-trackback.php
    xmlrpc.php


Is it a good practice to make sudo ask for root password in a single-user system?

Yes, you should.

In a brute force attack against the raw hash, sudo won't help you. However, you should be aware that in other attacking methods, sudo is able to offer some protection.

If, for example, an attacker is able to break into your machine with an exploit, he does not know the password. Potentially delaying or stopping an attack as the attacker does not have the proper privileges to carry out system commands.

However, sudo should be a last line of defense. Once an attacker is in, they are in. Privilege escalation is a commonly practiced strategy. An experienced attacker should be prepared to escalate privileges.


How can I protect my PHP app against XSS?

Apart from other mitigation techniques, do consider using Content-Security-Policy (CSP) to prevent against XSS vulnerabilities.

CSP

  Content Security Policy (CSP) is a computer security standard introduced to prevent cross-site scripting (XSS) : Wikipedia

It white-lists the domains from which a resource can be loaded. (resource could be : js, css, image etc)
You can add this policy in the response header, and browser will enforce it during any attempt to load resources.
It also comes with report-only mode, which can be used to evaluate the current state of your application before enforcing it.

A sample policy looks like :

Content-Security-Policy: script-src 'self' https://abc.com

With above policy, it will only allow to download javascript from page's current origin and abc.com. Any attempt to download from other source will cause an error like below in browser console :

Refused to load the script 'http://evil.com/evil.js' because it violates the following Content Security Policy directive : "script-src 'self' https://abc.com".

Do note that it's only supported by major browsers; like : Chrome, Edge, etc.
Similar restrictions can be applied to other resources as well.
For further reading, here is an awesome article explaining everything you need to know about CSP : https://www.html5rocks.com/en/tutorials/security/content-security-policy/


Yes, it is injection because you are injecting your code into the existing SQL code.

For example. A common way to log a user in using php and SQL looks like this:

$sql = "SELECT * FROM users WHERE username = '" . $POST['username'] . "' AND password = '" . $POST['password'] . "';"

The variables $POST['username'] and $POST['password'] what the user puts in the login fields. If the user entered the following.

' or 1 == 1 ---

The resulting SQL that is executed looks like this:

SELECT * FROM users WHERE username = '' or 1 == 1 --- AND password = '';

Notice that everything after the "---" is a comment and ignored.  So the sql looks to see if it can find a username that matches null or 1 == 1.  Since 1 always equals 1, the SQL will return true and log the user in.

This is called injection because the user is injecting their code into the code the developer wrote.


This attack is still working for outdated web browser! But the reality is that most of the servers now a day have HSTS (HTTP Strict Transport Security) enabled.

So how to sslstrip even if HSTS it dose his job?

If you use a virtual machine use your internet adapter on bridge mode.
Use sslstrip2 or go for a MITM framework like MANA or MITMF they tend to be more stable.
Be sure that if the target wants to reach as an example facebook.com to redirect the target to social.facebook.com (were HSTS security policy dosen't remember any certificate) and then you could perform an MITM SSLStrip.
Be sure to use a proper Wifi adapter that also support packet injection.


Update: As pointed out by Moti Korets here, my answer relates to "Vector Ultra Mini Httpd", not "ACME mini_httpd" that I now realise was being asked for by the OP.

Vector Ultra Mini Httpd

No it is not secure.

Even the latest version, v1.21 suffers from a serious stack based buffer overflow meaning that a remote attacker can gain control of your system. CVE here.

ACME mini_httpd

See jimis excellent answer here.


Carrying out a professional IT audit procedure

This is a much bigger question than I think you realise - for a start, the major IT audit firms have a very large amount of Intellectual Property in this area, so while you will be able to find high level documentation, you may have trouble finding full detailed documents.

From my time in a Big-4 audit firm, I probably saw over 300 workplans for audit of specific technologies, and contributed to maybe 50 of those. The time investment is pretty high.

In saying that, I would definitely suggest you join ISACA (the Information Systems Audit and Control Association), which is the definitive body for this industry. A vast amount of information is available through ISACA, including CobIT and audit guidance.

(disclosure - one of my roles is President of the Scottish ISACA chapter)


Is AWS Elastic Beanstalk traffic from load balancer to backend EC2 instances secure?

It depends on your risk model. Unencrypted communication between two servers in the Amazon cloud is 100% visible to Amazon, for instance. It is also visible (and modifiable) to anyone, be they disgruntled employee or successful attacker, that has administrative privileges on anything in between those two servers. If that is worrisome in your context, then it's not sufficiently secure for you.

Thanks to Amazon's security, it is substantially more secure against everyone else than the general internet, but it is also extremely vulnerable against Amazon.


The whole setup seems kosher to me. But I feel that too little is known about the application itself; did you consider the possibility of the password being leaked, or the decoded keys?

On some (web-based) systems, you'd have to "store" some or all of that data in a session object, which could well mean that the information is archived in plain text in a file on disk, or a key-value pair server, potentially accessible by other users as well as rogue processes, and possibly remaining accessible long after the user has logged out and disconnected. On such platforms you'd need to manually sanitize your data structures as far as possible; also, key-value assignment is non-trivial and typically requires a fairly unguessable session ID generator (which most aren't; unguessable, I mean).

You appear to already know about this, but I'll refer to session fixation nonetheless. Also, memory databases and key-value stores might, for performance's sake, not properly initialize their memory and allow an attacker to recover sensitive data; typically you use low level API to request a 4K block, and read off it before initializing it. If the server did its homework properly you'll get 4096 zeroes. If it did not, you'll get whatever was stored in that block by the user before you (I saw this happen in a BANK, of all things).

Then, access to those databases must be protected or secured somehow - a third party shouldn't be able to access data it has no right to (for example by enumerating stored datasets and querying their contents). On some systems you could use a different, totally unrelated (and vulnerable) virtual host to gain access to the content of such a keystore, by misdirecting the server into retrieving the wrong keyvalues. This caused an error, but sometimes the error text included precious information:

We're sorry. There is no document called
    *?=|1395481948749|1346625
   |lserni
   |62609098affb79cd2e7c31b6793b539e
   |Fl==SPQR].
(Error: DB001A key was not found)
Try using the Search function, or contact us with the details of this issue.

Hypothetical example, attack #1

website process with PID 12345 connects to keyserverd:
    >> "store value '<PRIVATEKEY>' into key 'pk-12345-1395494389'"
    << "OK"

rogue process espies PID 12345 and knows the timestamp. It also connects:
    >> "Get me key 'pk-12345-1395494387'"
    << "ERROR: no such key"
    >> "Get me key 'pk-12345-1395494388'"
    << "ERROR: no such key"
    >> "Get me key 'pk-12345-1395494389'"
    << "OK: <PRIVATE KEY>"

This may happen during the process lifetime, or can happen afterwards. Unless of course:

    >> "Logging out. Delete key pk-12345-1395494389"
    << "OK"

Hypothetical example, attack #2

Just as before, but this time the API is more complicated (at low level, of which you might not be aware):

application (to library): "Store value '' into key 'pk'"

library: generates unique pk-12345-1395494389
library: connects
library: requests 1880 bytes for pk-12345-1395494389

server: allocates 1880 bytes plus necessary housekeeping structures
server: returns handle 123

library: stores '' into handle 123
...

application (to library): "Delete value 'pk'"

library: determine pk-12345-1395494389
library: deletes pk-12345-1395494389

server: marks 1880 bytes as "free" but DOES NOT OVERWRITE THEM
server: destroys handle 123

attacker: request 1880 bytes for key "pwn"

server: allocates 1880 bytes plus ... and these are THE SAME BYTES FREED
      A MOMENT AGO

attacker: does NOT write anything to key 'pwn'
attacker: read content of "pwn" memory block
 (sometimes this is not allowed, but the memory is nonetheless accessible
  in some roundabout way. Some other times it isn't, but you can't count on
  getting a break)
attacker: finds "" (or sometimes "@#£!VATE KEY>")

In such a case:

    >> "Logging out. Store '##[...1.8Kb of #'s...]###NICE TRY!'
                into key pk-12345-1395494389"
    << "OK"
    >> "Delete key pk-12345-1395494389"
    << "OK"

is slower, but more secure ("memory shredding" or "memory scrubbing").

In such a scenario, storing data to the database is as good as having passwords in cleartext; actually it's worse, because while a user must have file system access to the database files or authentication to the database server in order to reap the passwords, in many instances keystores are designed for "we're among friends" access, and anybody with local access can retrieve data (e.g. Redis "is designed to be accessed by trusted clients inside trusted environments"). This is OK, mind you, as long as you know what's happening and take countermeasures. After all, the Internet is insecure and yet here we are creating websites - but we use authentication and SSL when we need them, for we know of the insecurity. With Redis for example we could turn on authentication; now the attacker has to have both local access and the password, but the password is in the webapp files, so he needs read access to those files, too. If we make it so that this equals to impersonating the webapp user, we're (more or less) done: because a local attacker with webapp impersonation capabilities could just ask the password to any user and/or mount a man-in-the-middle attack. Of course this is all very, very rough; you need to examine your own workflow and ask yourself, "What could one do who arrived at this point? What else could he do? How do I take him out? How do I keep him out?".

Desktop applications also have their own insecurities related to password and plaintext data persistence both in memory and on disk (you have to treat specially the sensitive memory region to prevent it from being cleartext swapped on disk, and have to scrub the memory manually before freeing).


A DPI solution cannot do targeted blocking when ESNI is used just by looking at the TLS ClientHello. But it can simply block any use of ESNI - see China is now blocking all encrypted HTTPS traffic that uses TLS 1.3 and ESNI.
Apart from that ESNI is not a thing an end user could actually enable globally. ESNI needs support both by the HTTPS server itself (or the reverse proxy in front of it, like in case of a CDN) and must also be setup in the DNS for the domain. And even with ESNI enabled and not blocked one can still monitor which IP addresses get visited, which can often be mapped to one or few domains served on this IP.

... what else should I enable to bypass DPI firewall without having to go the VPN route?

The proposed solutions don't provide adequate protection as described. There is no additional thing to enable to bypass the DPI. Instead use a VPN, HTTP proxy over HTTPS, SOCKS proxy over TLS or similar which transfers all traffic encrypted to a trusted endpoint, bypassing the DPI.


OpenSSL oracle padding vulnerability (CVE-2016-2107)

A 'padding oracle attack' has nothing to do with the Oracle database software.

Ensure windows is updated, and remove the insecure cipher suites that this machine was configured to use.


How exactly are registration authorities related to certificate authorities?

This process of enrolment is made confusing unintentionally.

In many cases the RA and CA are the same entity. An easy way to see this is with common SSL/TLS certificates. Godaddy, Comodo, and others will offer a EV SSL (Extended Validation SSL) Certificate. The corporation who offers the certificate, validates the end user's information as well as actually issuing them a certificate.

To create a full chain of trust, the RA and CA should be separate entities. In a system like ICAO's PKI for ePassports, this system is much more evident. There is a document signing certificate (DSC), a country signing certificate (CSC), and sub certificates for each issuing office in the country (issuer security certificates or ISCs). It's not very evident when inspecting the raw certificates in ICAO's PKI, but some countries do seem to follow this full model.

The immediate benefit of this "full" model is that a revocation list can target a specific issuing office's certificates, rather then one for the country.

You can read more about the PKI structure ICAO employs below:

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

http://www.icao.int/Security/FAL/PKD/Pages/default.aspx


icmp packets not able to reach the firewall despite of adding a specific rule, why?

You have the rules backwards. In INPUT you must have icmp-reply and in OUTPUT icmp-request


Will wireless isolation/AP isolation protect from KRACK?

Nope.

Wireless/client/AP isolation only provides a means of isolating one wireless client from another. It has no bearing on how 802.11 encryption works or how the WPA2 handshake takes place.

Since KRACK attacks the WPA2 handshake and compromises the encryption between a client device and the access point, it really doesn't care if the wireless client can reach another wireless client.


You can replicate SSLStrip's functionality using a Mitmproxy script. In the examples directory of the Mitmproxy source tree, see sslstrip.py.

You can simply modify the request or response functions in this script to perform the custom injection that your own script does.


Yes, the answer is simple. Go to the Facebook App's settings page and turn on "open with external browser" or somesuch, and the infernal internal browser in the FB app will be silenced!


Why does Mark Zuckerberg cover his headphone jack with tape?

This is a useless question but still interesting one :)

and that is not audio jack

He is a security freak like me, not real freak but there are some people who really care for their device security and of course a CEO will have some serious data inside his laptop, I am sure you understand that covering mic and cam is so that even an un-authorised access to his cam will not reveal his face or sounds of the surroundings. Mark really cares for security, like he doesn't want to leave a single loop hole or any kind of vulnerability in his system that's why he even released a sort of security contest where you will get awarded with money if you can find a vulnerability in his Facebook System.

As I did search for his laptop, I found about the laptop, it's MacBook Air (and I precisely got the image of left side of that laptop) and you can see here in the image that before headphone's jack comes an inbuilt microphone, and of course it's not a microphone jack, it's an actual inbuilt microphone as jacks aren't that small. So you see, he is again covering his microphone so that hackers can't access sound even if they got access to his Macbook's microphone

so in summary:-

He covered his top cam and then covered his left side inbuilt mic so that no un authorised access can harm him, basically doing the best to stay from hackers and getting hacked or any kind of personal audio/video from getting hacked & released. So even if hackers hack his laptop successfully, they won't be able to use his webcam or mic


How Point-to-Point encryption eliminates PAN storing?

P2PE usage can eliminate PAN storage, because the POS system will not have access to the cleartext card data to retain from the start.  However, if you need to run subsequent transactions on the same card, such as returns or adjustments, P2PE alone will not help you there. You need to understand from the vendor what your options are.   Their answer may be to say that you will need to contact the cardholder to re-provide the PAN for any subsequent transactions.

To address the problem in a more palatable manner than that, many solutions offer both P2PE and a tokenization feature.  Rather than keep PANs, you would store a token and use that in follow up requests.  The processor/gateway/other relevant solution provider would then swap the token for the PAN when you send them a transaction.


The server can ask the browser to set cookies with the secure flag on over HTTP, but the browser should only include them in responses via HTTPS.

But you should never present a request for authentication over HTTP direct responses to authentication requests over HTTP. The former may be tampered with to copy the credentials elsewhere, while the latter can be sniffed.

Mixing and matching HTTP and HTTPS is not a good recipe for a secure site. They should be clearly delimited.


Should I let a user know they have entered an unknown username or email address?

The answer is generally it depends. This is really based on the security of your system.

Users can create new accounts without restriction

If so, it is kind of meaningless to not tell them. You can't have intersecting usernames or email addresses, so you have to inform a new user if their username or email has already been used. An attacker would then be able to obtain the usernames and emails by attacking the new user registration system. Giving them a similar venue to attack in the forgot password section does not harm your security any because the method just exists elsewhere. Just make sure that the restrictions you use in the registration system are the same as the restrictions for requesting a password (that is whatever anti-spam system you use).

Users cannot create new accounts without restriction

Consider an invite only system. The only way you are allowed to register is if someone has authorized it. This could be an instance where an administrator sets your initial username, email, and password (potentially manually). This system would allow you to gain security by not telling users if their entered information is correct or not. Usernames and emails could then be treated as a weakly guarded secret.

Overall

Note that this is a hit to usability. If someone mistypes their email address, they may not notice that they did. Emails from websites don't always come through immediately, so a user could be waiting for an email that never comes.


Can governments intercept end-to-end encrypted Whatsapp communication through lawful interception?

It's very unlikely that any government agency would crack the encryption. They would need the key. And the only way they could get that is if Whatsapp had a backdoor or weakness in their software which allowed for such a key to be extracted.

There is, as of today, no direct evidence that such a backdoor exists in Whatsapp. But, since Whatsapp is closed source, it also becomes difficult to make sure such a backdoor does not exist.

However, in terms of information security, what we are interested in is a risk assessment. Considering OP, government agencies are the parties we are being asked about. We should therefore asses that risk. Here is some relevant information regarding that:

Whatsapp's parent company, Facebook, has been shown to give the NSA direct, unilatateral access to their servers through something called the PRISM Program. While Facebook denies this, it has been proven by leaked documents. This does not, however, mean that the NSA can decrypt Whatsapp messages. I include this information in the risk assessment as an example of Whatsapp's owner's relationship to the NSA and privacy transparency in general.

In 2013, information was released regarding: (Source)

  • NSA and GCHQ unlock encryption used to protect emails, banking and
  medical records

  • $250m-a-year US program works covertly with tech companies to insert weaknesses into products

We can absolutely not prove that this large, covert program has in fact worked with Facebook to put such a "weakness" into Whatsapp. However, this information is nevertheless relevant to our risk assessment. If such a weakness was actually implemented, it could compromise the encryption key.

Though not absolutely identical, considerably similar things have indeed happened before. Here is one example regarding Skype, Microsoft and the NSA.

Conclusion: It is, at present, difficult to conclude one way or the other. Whatsapp's parent company (as well as other companies) have demonstrated in the past that they are willing to give the NSA unilateral access to user data. They have also shown a willingness to lie about it. Given this, it seems difficult to take companies under the control of Facebook at their word regarding this particular subject.

When we evaluate the degree of risk in regards to malware, a virus, being hacked, data loss, data theft, surveillance, etc, it is not only relevant if something is proven. It is also relevant if something is possible or even likely. While, in this particular case, there may not be sufficient grounds to say that the NSA gaining access to Whatsapp encryption keys is likely, it is definitely possible, given the history of these entities.

This is something people can take into consideration when evaluating such a situation.

Related reading:

New Snowden Documents Detail How NSA Can Bypass Common Internet Encryption (International Business Times)

Microsoft handed the NSA access to encrypted messages (The Guardian)

Revealed: how US and UK spy agencies defeat internet privacy and security (The Guardian)

PRISM (surveillance program) (Wikipedia)


Am I preparing for a career in cyber security AFROTC properly?

Full disclosure, I am prior Air Force and I will answer your questions to the best of my ability.

1.) USAF Officers: So, it seems as if you are still attempting to define how you are going to enter the USAF (i.e. Enlisted/Officer). This is priority #1 before you make any decisions going forward. If you have a 4 year degree completed in a needed field (Mathematics, Cyber Security, Physics, Meteorology, etc), then you should be able to get passed the recruiter and take the AFOQT - Air Force Officers Qualification Test. The test will either deny or accept you entry to Officer Candidate School. However, since you are still is HS, start looking at schools with a ROTC program and a CyberSecurity/ Information Technology Security Major. These should be your first steps

2.) USAF Enlisted: there are sysadmin, network engineers positions within the enlisted ranks. I am not so certain on cyber security though as that takes lots of training and education which, is really more of an officer AFSC. If you are thinking of enlisting for cybersecurity, I would just ask you to go look at ROTC programs first since that will be a much better solution which a much more guaranteed AFSC, and you're setting yourself for a much brighter future.

3.) Linux: Understand it, know how to use it well, Linux is your friend and ally when it comes to pen testing and hacking in general. With that said, you need to understand windows very well too. The USAF and most cyber commands for that matter will have a subset of tools and procedures that you will need to follow if you enter in the service. Just try to learn as much as you can about as much as you can.

4.) Certifications: OSCP is a bitch, if you're going to focus on some certifications, focus on one at a time IMO. If you are studying for OSCP, just study for OSCP! But you should really figure out what you want to do. If it's offensive or defensive security, then from there narrow it down as much as you can.


Don't embed a hard-coded key into your application; that provides little more than a trivial obfuscation for anyone that reverse-engineers your application.

To generate a key for encryption, use a key-derivation algorithm such as PBKDF2, which essentially performs hundreds of rounds of a hash function on a password, combining the results together to produce a secure key. To help understand why you need a key-derivation algorithm, take a look at this other answer.

The benefits of PBKDF2 are:

Configurable number of rounds, to tailor computation speed to your device whilst maintaining a reasonable security margin against brute-force.
Provable security, i.e. it is at least as strong as the underlying hash function.
Can produce any size key.
Easy to implement (there's already a Java implementation for you)

Essentially you let the user put his/her password in, then compute the key using PBKDF2, then use that key to decrypt/encrypt the data.

Now, as far as the actual encryption goes, I highly suggest sticking to something easy if you've not dealt with crypto before. Block ciphers have to be used in a mode of operation, and require an initialisation vector (IV) in order to be secure. There's a lot of implementation details that have to go exactly right in order for it to actually be secure, so in this case I suggest reading various other questions around here to understand them further.


When would one use a password hash instead of a KDF?

A password hash is a KDF, but not all KDFs are password hashes. Password hashes have the additional requirement that they allow configuring how slow they are, while some KDFs do not have this ability.

For instance, HKDF is a KDF designed to allow deriving keys from an existing high-entropy key. This is useful when you already have a single key (either generated randomly or from a slow KDF like bcrypt, Argon2, PBKDF2, etc), but need multiple keys.


Testing malware or bad url's from a SIEM

If you have no skills in malware analysis and reverse engineering, you should try Free Automated Malware Analysis Sandboxes and Services first and install a hardened Cuckoo Sandbox in a VPS to get a detailed dynamic analysis.

To do malware analysis and reverse engineering in a VM safely and effectively, you need to learn a lot from books, videos, articles and tutorials. Browsing the website Tuts 4 You would give you lots of useful reading materials.

Practical Malware Analysis: The Hands-On Guide to Dissecting Malicious Software [Michael Sikorski, Andrew Honig] is classic book for you to start the malware analysis journey.

Reverse Engineering for Beginners is a good frequently updated book to learn reverse engineering.

Open Security Training provides high quality free courses on reverse engineering & malware analysis topics.

Hasherezade has more tips for you on her blog:
https://hshrzd.wordpress.com/how-to-start/


The presence of some security controls does not make a system secure.

Yes I think you have identified a valid problem but that organization could still truthfully say the confidential data was never sent in an unencrypted fashion.

Unfortunately there are many vendors touting things as being secure because they either have some security controls or because they can protect from one particular attack vector and if the consumers aren't asking the tough questions they are unfortunately unaware of the shortcomings in any given solution.


Multi-factor auth: implementing a "don't ask again for this computer" function

Pinning the cookie to the IP is not practical. Imagine a mobile phone that is constantly switching networks.

I heard about pinning the cookie to the SSL session keys in high security applications. The server would allow a specific cookie only if it comes over the specific SSL session that was used to initiate that cookie.

A different way of making the cookie unusable on a different computer is fingerprinting the original computer. The combination of, OS, browser, screen resolution, installed add-ons, can form a unique fingerprint that identifies one computer.

When Heartbleed hit and session cookies were exposed, a lot of second factor authentication became useless and the "remember me" worsen the problem because cookies did not expire at the end of a session.

The "remember me" functionality is for convenience. Convenience is almost always at odds with security. Imagine using voice recognition in your office to conveniently input passwords and the second factor. Multi factor decreases convenience and increases security.

In fact, multi factor authentication asks for multiple inputs from the user while the "remember me" is used to ask for less inputs. You are asking for something that increases security and convenience. That is where research into new authentication is currently applied. Biometrics, personal devices and other technology is working toward that goal.

Services like LastPass and KeePass can provide the illusion of the "remember me" and still have heightened security.
Google is working on a ring and a technology that uses your smartphone and inaudible sound to authenticate the user.
YubiKey is a hardware device that can eliminate remembering and typing of passwords.


I'm surprised I got attacks through the program.

The word "attack" is likely an exaggeration here. Probably you just hit a site which has a very low reputation and has served malware in the past, i.e. "Malicious Domain" in the message. Nothing attacked you've actively here.

Is it safe to do web scraping to such a random big list of URLs, or the attack notifications are ignorable

It depends a lot on what you are doing in detail. If you just make HTTP requests and responses and follow links with some simple program than it likely can be ignored. If you post-process data like converting images etc it might be more of a problem since this might trigger security issues in complex libraries. Of course this assumes no newly introduced security issues by programming errors in your code or used libraries, i.e. data from the internet should always be treated as untrusted and no assumptions about their content and format should be made without explicit verification.


You must check the version of your glibc first: using this command can help:

ldd --version

The end of the answer has a good things you can skip and go there

According to this reference this vulnerability works on glibc version before 2.21-3.
if your glibc is older than this version it is vulnerable.

The problem has been fixed upstream but a new version has yet to be
released.

Also there is another vulnerability that Last revised is: 04/13/2015 and also is related to glibc version 2.20 and before it.

Also read this one: Red Hat alert RHSA-2015:0863-01 (glibc)

Arjun Shankar of Red Hat discovered that the nss_dns code does not
adjust the buffer length when the buffer start pointer is aligned.  As a
result, a buffer overflow can occur in the implementation of functions
such as gethostbyname_r, and crafted DNS responses might cause
application crashes or result in arbitrary code execution.
This can only happen if these functions are called with a misaligned
buffer.  I looked at quite a bit of source code, and tested applications
with a patched glibc that logs misaligned buffers.  I did not observe
any such misaligned buffers.[Reference]

GHOST gethostbyname() heap overflow in glibc (CVE-2015-0235)

This is another vulnerability related to glibc and gethostbyname() this artice said:
"to the best of our knowledge, the buffer overflow cannot be triggered in any of [these]:

apache, cups, dovecot, gnupg, isc-dhcp, lighttpd, mariadb/mysql,

nfs-utils, nginx, nodejs, openldap, openssh, postfix, proftpd,

pure-ftpd, rsyslog, samba, sendmail, sysklogd, syslog-ng, tcp_wrappers,

vsftpd, xinetd."

So I think like this vulnerability your mentioned vulnerability does not affect on apache

and maybe this vulnerability has an effect on Apache or maybe not, but untill clarifying this issue. the fast countermeasure is upgrading glibc to last version.


Metasploit automatic module execution on receival of shell?

The handler has an AutoRunScript option which specifies what happens when a session is received. You can give it the multi_console_command script which will be able to execute multiple post modules and meterpreter scripts upon receiving session.

For example, in order to run the smart_migrate and killfw post modules:

msf > use exploit/multi/handler
msf (handler) > set AutoRunScript multi_console_command -rc /root/mycommands.rb

The contents of /root/mycommands.rb include:

root@kali# cat /root/mycommands.rb
run post/windows/manage/smart_migrate
run post/windows/manage/killfw


Is encrypted cookie without authentication secure enough?

Yes you need a MAC in order to ensure the user hasn't manipulated the value to something else which is a valid user id once decrypted.

Also, rather than MAC <userid> you should add some context around it, and then mac that.

e.g. userid=<userid>

This will prevent a substitution attack elsewhere on your site with data that has been MAC'd. For example, if there's a page on your site that an attacker needs a MAC'd 100 to pass to it. e.g.

example.com/view_order?order_id=100&mac=****

The attacker does not know the MAC to input. However, the user can create users and their recently created user has user ID 90. The attacker simply creates 10 more users and has a look at the created cookie. As this will contain the MAC for the number 100, they can then substitute in the value to their URL request above. This is why context matters when creating MACs.

Additionally, you should ideally include an expiry date on such data to prevent replay attacks at a later time.

e.g. you should mac userid=<userid>&expiry=20160203120000


Help! What is this remote takeover / malware from a pop up, and what does it do?

There is a setting in Chrome to block popups but this does not mean that all popups are blocked. There is actually a valid use for popups for example to notify users that they have entered invalid information or similar. Disabling all popups would thus render some innocent sites unusable. That's why browsers employ heuristics to decide when a popup gets shown and when it gets blocked. A common part of such heuristics is that popups as a result of user interaction are allowed, i.e. if the user entered some information or clicked a checkbox or similar.

In your case the popup was shown after you've clicked on the torrent, i.e. after you've explicitly interacted with the site. Therefore the popup was probably considered valid by the heuristics and shown.

But it might also be that it wasn't actually a real popup at all what you saw. There are various ways to render information which might look like a popup but are not. For example one could create a HTML div section with a negative z-index  and an absolute position which will thus overlay the existing site and look like a popup. See here for an example.


However, I could not find anything about if the bug in gets is fixed or not i.e. whether gets, scanf, fscanf etc. check for bounds on input buffers or not.

With some understanding how C works or a look at the documentation it is actually hard to miss that these bugs are not fixed and cannot be fixed while keeping the same function interface.

Given that these functions only get a pointer to a buffer (char*) and not the size of the buffer and given that there is no implicit size is associated with the buffer in C, it is impossible for these functions to check the (unknown) bounds. This means it is impossible to fix these insecure-by-design functions will keeping the API.

This is even clearly described for example in man gets:

  Never use gets(). Because it is impossible to tell without knowing the data in advance how many characters gets() will read, and because gets() will continue to store characters past the end of the buffer, it is extremely dangerous to use. It has been used to break computer security. Use fgets() instead.

  Also, is there any study or estimate about what would be the cost if someone is able to launch an attack similar to that today?

I'm not aware of any serious research and I could not imagine any since there are too much unknowns: how far could the worm spread, what is the actual damage it does on each system... But, if such a worm is successful the damage will be much higher than in the past since way more systems are connected together and also the criticality of these systems is much higher. I recommend to have a look at recent attacks like WannaCry.


What is the need of "password" grant-type in OAuth 2.0?

First thing is that we should try to avoid password grant type as much as possible. But the reason why it is there is because it is better than storing the password.

Reasons:
Password grant doesn't need user to store his/her username password in the client. It is used only once only to get the access token.

Storing only the token is secure than storing the password in an external application (mobile aps, server side apps etc)
If user changes the password at the IDP, then app will again have to ask the user to enter his new password. This is not a good user experience. But in password grant-type, app can use the refresh token even when the user has changed the password.


How does the anchor tag () let you do a stored XSS?

If you want to get anywhere in security and finding bugs, bypassing security measures you need to start to get more creative and more experimentative (if that's even an english word).

In this case:

Choose an input.
Feed it through the black box.
Get the output
Make a theory: How does the black box transform my input -> output
Choose a different input and repeat until confident that you're theory is correct.
Adapt/update/change theory with new information from (input, output) pairs.

A possible theory in this case would be that the black box simply replaces https with an empty string. How do we verify this: Well... we enter "hihttpsthere" and see if we get "hithere" as output. But it transform javascript:alert(7) to (//javascript,:alert(7)) so maybe it's splitting at :? Maybe it tries to parse the protocol of the URL? Use some urlencoded stuff, use non-printable characters, maybe even use a fuzzer? It could even be that their filter makes an XSS impossible.. could be. You'll have to find out.

It's all about trial and error.

  I was trying to get xss but site valdiate input

That's what it's supposed to do anyway. You can't expect that you can do an XSS everywhere.


Snowden: "The NSA can remotely turn on your iPhone."

There is a semantics issue at play here that make answering definitively very difficult.

What precisely did Mr. Snowden talk about when he said "Yes they can turn your phone on."

Did he mean activate a device that is in a shutdown (not standby, low-power-ready-to-function) state?

Doubtful.

Did he mean activate a device in a low-power, standby state?

Possibly. This is a no brainer, and exactly one of the features a "stand by" state is intended to facilitate. A carrier or gov agency exploiting it via code or warrant is nothing surprising.

Did he mean 'turn on the microphone or other sensors when an active call is not in progress, to allow recording of ambient noises and conversations near the device?'

Probably, and this is a known capability of service providers and thus government agencies for some time.[1]

[1] http://en.wikipedia.org/wiki/Covert_listening_device#Remotely_activated_mobile_phone_microphones


How do TV satellites authenticate the receiving signal to make sure its from the TV station that its claiming to be and is not spoofing?

Almost every commercial satellite is just a repeater. They have a sensitive receiver and a powerful transmitter, a couple filters, and basically is that. They almost never employ any encryption at all, because sending a computer in the space is expensive, as more weight means more money. And you cannot just send your average Intel processor over, you must design a radiation resistant computer, shield its components with heavy metals (adding weight). So no, just send a repeater.

The security of the satellite is based on the difficulty of interfering with it. Anyone trying to jam a satellite will need a powerful transmitter, a good antenna, and internal knowledge of the receiving band of the satellite. Knowing the frequency is not enough, they need to know the protocol, and that is not just a Google search away. Most of the satellite communication hardware is protected by patents and industrial secrets. They are not usually available.

A radio antenna is not like a laser bean. It radiates on every direction, but with different power levels. It's something called Radiation Pattern. Any good antenna will radiate almost all power in the desired direction, but some power will "leak" around the antenna, even behind it.

Another difficulty is the power level. The power needed depends heavily on the bandwidth. You can send a few bytes per second over a 25mW transmitter to 700km away, but you cannot transmit HDTV to over 35k km on a sub-kW transmitter. And that is expensive and difficult.

So, a transmitter powerful enough to send data over the upper atmosphere to a satellite receiver will leak a lot of power around his antenna, not only on the main frequency, but on the neighbor bands too. That will interfere with the communications of a lot of people - the ham radio operators. And they are professionals, they hate people interfering with their spectrum, and they have knowledge, equipment and motivation to detect the source of the disturbance. Try buying any cheap transmitter on eBay, modify its amplifier to output more power, and let it transmit something for 24h. Someone will knock on your door. Fuming. So don't do that.

So while it's possible, no attackers will do this because:

it's very expensive
technically difficult
getting caught is very easy
the fines for doing so are astronomically high
and the most important: what would they gain?


Would Axolotl Ratchet protocol be suitable for encrypting email communication?

Neat idea, good question, but there are a couple issues that make axolotl not a good drop-in solution for existing email clients and/or servers:

1)  The asynchronous part of TextSecure requires help from the server that email servers don't provide.  Specifically, TextSecure/Signal servers distribute ephemeral public keys for offline users.  Email servers don't.

2)  Axolotl clients are necessarily stateful, tracking the key ratchet for every conversation.  It is (again) just not a function that email clients are built to provide, and it makes having more than one email client hard, because it necessitates synchronizing that state between one's email clients.  E.g. your desktop email client must get all the keys generated by your smartphone email client.

It could, however, be a good email replacement.  If you want to work on that problem, check out the web client in development for TextSecure, or Pond.  Textsecure/Signal needs a desktop client, and Pond needs a mobile client.

While the axolotl ratchet is brilliant and offers some great security properties, there is an argument to be made that the security guarantees that axolotl provides are not worth the state-maintenance hassle for a lot of use-cases.


The short answer is no.  XSS is client-side injection used to attack browsers, meaning the attack manipulates the webpage which shows up in the user's browser.   In order to perform XSS attacks, you need to use HTML/JavaScript (C will not work).   As XSS is an attack against the browser, the only way to attack a linux system is if the browser is running on a linux system.

Theoretically, if you could leverage the XSS attack to get the browser to load a malicious Flash object which exploits a buffer overflow/other bug, you could get arbitrary code execution on the system, and then exploit a privilege escalation bug to get root access.  Theoretically do-able, but it relies on many other bugs to do the actually privilege escalation, and there are probably much easier ways to accomplish your goal.


Malware / vulnerability that uses or causes malformed IP or TCP Headers

There have been vulnerabilities in hosts with imperfect TCP implementations where malformed requests could cause a crash. I don't know that I've seen anything infect a machine and then choose to break TCP by toying with the headers. Here's an example of a bad-header-caused crash bug:

http://blog.jeremyrossi.com/juniper-flaw-exposes-core-routers-to-kernel-crash.html

Using the reserved bits (6 bits in IPv4) in the header would be very inefficient and it's not something I've ever seen in the wild. It's plausible but generally speaking I wouldn't expect to see it since it's something very unusual and would be easy to identify and filter. I looked around online and could not find anything solid identifying this behavior in use today.

There's a SANS paper on using parts of the TCP packet for covert data passage that covers some of this topic pretty well:  https://www.sans.org/reading-room/whitepapers/covert/covert-data-storage-channel-ip-packet-headers-2093


The other answers are correct, however there is one big fish being mostly ignored:

  DNS cache poisoning

As @Larry said, since you own the router you own the DNS. Meaning you can cause any other user of that network, use any server you want for any address they request.

But more than that:

You can make leave your DNS ownership in place, even when you're not there anymore other users will continue to use your servers.
Even after the other users leave, you can still own whatever address they try to access.
To clarify, let's assume some victim at some point uses the coffeeshop to access http://www.google.com/. This should resolve to 209.85.143.104. However, because you pwned the router, you're sending anyone who requests http://www.google.com/ to 207.200.14.140. This will continue to happen, even after you go home...
Now, what happens if you set the TTL for the DNS response (the one returning 207.200.14.140 for http://www.google.com/), to some value far in the future? The victim will go home, back to his "secure" network, and at some point will again browse to  http://www.google.com/. Shouldn't be a problem, right? Well, the TTL caused the DNS response to stay cached on your machine, so your browser now doesnt even bother making another DNS request - it just sticks with the 207.200.14.140 it got at the coffeeshop. That you gave it. 3 weeks ago.

Just a suggestion? A bit borderline, but since noone at the coffeeshop cares (or probably even knows how to logon to a router what that even is), do them a favor: change the password for them. Write it down for them, hand it to the manager, and if he really needs it, he'll figure out what to do, and maybe even learn a lesson.
Of course, this is borderline ethical, maybe even illegal, so caveat emptor. But other users WILL be grateful (even if they know nothing about it).


OpenSSL Heartbeat (Heartbleed bug) - what's the payload used for?

The TLS "heartbeat" feature is intended for TLS over UDP or other connectionless protocols.  "Heartbeat" packets are a way of asking the server "are you still there?", but with a connectionless protocol, there's no guarantee that packets won't be dropped or delivered out of order.  The arbitrary-sized "payload" field permits a great deal of flexibility for telling one heartbeat packet from another.

The problem is that this flexibility is overkill for almost all uses: a simple sequence number or other fixed-size field would work just as well.