Is Adblock (Plus) a security risk? My email-provider's website (http://www.gmx.de) recently started linking to the (German) site http://www.browsersicherheit.info/ which basically claims that due to its capabilities to modify a site's appearance, Adblock Plus (and others) might actually be abused for phising. Here's a quote from that site plus its translation:

  Solche Add-ons haben Zugriff auf alle Ihre Eingaben im Browser und können diese auch an Dritte weitergeben – auch Ihr Bank-Passwort. Dies kann auf allen Web-Seiten passieren. Sicherheitsmechanismen wie SSL können das nicht verhindern.

translated:

  Such addons can access all your browser's input and can also forward them to third parties - even your banking password. This can happen on all websites. Security mechanisms such as SSL cannot avoid that.

Ok, they mention other (pretty obviously crapware) addons, but is Adblock Plus really a security threat or do that site's operators simply use the opportunity to try and scare inexperienced users into viewing their ads again?

It is not. This is a FUD (fear, uncertainty, and doubt) campaign by GMX because they want to display their ads. There is absolutely no security risk from the mentioned ad blockers. They added some crapware to the list to make it look more legitimate.

Of course such campaigns are very unusual, especially from such a big and well known company like GMX. Unfortunately, I have no English source at hand (because it's a German only campaign) but since you speak German you may want to read this article at heise.de.

Update #1: United Internet, the company behind GMX, received a lot of criticism for misleading customers by falsely claiming that there is a security risk on their PC. The Wall Street Journal (German edition) named the warnings displayed on GMX and the site they link to a "scare campaign".

Update #2: GMX now says that they will no longer display the link when you use ad blockers but will still display it if you use crapware that injects adverts, the list at the site http://www.browsersicherheit.info/ has been updated accordingly and now lists only a small collection of crapware. This list is by no means complete so it is not a reliable source when you want to know if your browser has crapware installed. However, United Internet still maintains it's position that they do not want users who visit their sites to use ad blockers and said they will develop other anti-blocking methods in the future (German source).


Is there more to password hashing? You have a plain text password and salt. The plain text password is assumed to be securely random and only known by the user and the salt is no secret and not necessarily unique but stored alongside the resulting hash. Is calling the following on its own and storing the result sufficient?

password_hash = Hash ( password || salt )

Where Hash is currently considered a "secure" hash function (sha512, BCrypt, etc)

Do people do more? Such as:

Multiple Iterations: Is there a huge benefit in running multiple iterations? If yes, is it purely a cost advantage? Is the number of iterations dynamic or static? How many iterations?
Multiple hash functions: Would there be an advantage in using multiple hash functions? For example, three rounds, sha512 -> BCrypt -> sha512?
Salt mixing Do people nest salts within a password or just concatenate on the end/start? For example, break the plain password into four sections, the salt into three and join each salt section in-between each password section.
Unique schemes: Would writing a unique password_hash function for each different project be of any benefit? For example, Project A's password_hash function runs SHA512 20 times and Project B's password_hash function runs BCrypt 10 times applying the salt at different ends of the password on each iteration.
"Black Magic": Is there a benefit in adding your own "black magic" to a hashing function? For example, before each iteration you apply some basic bitwise actions or mix up the characters based on a simple algorithm.
Obfuscation: Would encoding or obfuscating the generated hash to hide its originating hash function make a huge difference? Such as adding or removing N characters to the hash to hide its original length.

Are these actions really necessary, would they make a huge difference (if yes, in what way) and do people use any extra actions like the ones mentioned above in practice?

My Thoughts:

In the end whatever is done with the password will not prevent someone using a stupid password (like 'password' or '123'); other methods not relevant to this question will have to be taken. But it is possible through multiple iterations make the computation more costly thus slowing down or rendering an attack unfeasible by brute force.

Most actions mentioned above will make a large difference to someone who has already gained access to the list of users - emails, password hashes and salts, and wishes to recover the plain passwords. It would not prevent a determined hacker but will deter and hopefully slow them down to give you enough time to make appropriate changes or actions to secure the compromised accounts.

However a lot of this goes against the idea that "the attacker knows all". Assuming the attacker can see how the password hashes were generated (source code and schema) it would make little difference. It would be as significant as changing a database tables column name from password to ahoy

Regardless, just using password_hash = Hash ( password || salt ) seems too straightforward. Surely people do more?

Multiple Iterations - This helps.  Its called key-strengthening and it raises the computational complexity.  E.g., if you key-strengthen by a factor of a 1000, an attacker can try 1000 less possible passwords in the same amount of GPU/CPU time.
Multiple hash functions - In theory this helps but not really in practice.  The case would be if one hash function used is somehow broken (e.g., you can reverse any 256-bit hash by trying significantly less than 2256 passwords or can significantly simplify the brute-forcing process while trying common passwords), but the other hash functions used in the chain are not broken.  E.g., that your attacker has broken iterated sha512, so can quickly come up with a password that works for sha512 key-strengthened N times, but not sha512(salt||bcrypt(salt||sha512(salt||pw))).  However in my view with modern cryptographic hash functions and typical attackers, that's a fairly unlikely attack scenario -- there are much lower hanging fruit that don't require the attacker to be make fundamental advances in computer science.    Possibly NSA or serious academic computer scientist may come up with clever ways to break hashing algorithms, but not your average malicious attacker.  Also even among hash algorithms that are broken and should generally be avoided (e.g., MD5 and SHA-1), they are usually only broken to collision attacks (find a pair of distinct strings s1, s2 that satisfies hash(s1) == hash(s2) much quicker than expected), but not preimage attacks (given a hash h find an s that satisfies hash(s)=h), which is the relevant attack on a password hash.
Salt mixing - This is an implementation detail, and doing it adds no complexity to an attacker.  (Precomputed rainbow tables for complex key-strengthened salted hashes don't exist.)
Unique schemes - Again an implementation detail, and adds no security.  Also don't run bcrypt multiple times; that's silly.  Bcrypt is already key-strengthened.  E.g., if you hash using bcrypt with a cost of 16, that means the key went through 2^16 ~ 65536 rounds, so if you want a stronger hash just increase the cost (every increase by 1; means bcrypt will be twice as slow).
Black Magic - As a programmer, I wouldn't suggest doing this; as black magic is a maintainance nightmare for you and your team, and again not too significant for an attacker to overcome.  Decision comes down to adopt a new technology, so you have to rewrite the non-standard hash routine in a new language on a new platform and unless its very well-documented you may do it slightly differently breaking the system.  And if it is well-documented, an attacker may steal your source code; see what the function does to a password and then can use for their brute forcing.  If they manage to steal your hashes, they probably have at least one account where they know a password and stole the hash, so can try reverse engineering it (even if they didn't get the source code).  Its like obsfucating your source code on your own server.  Its more a hassle for you the developer/maintainer, not really for attackers.
Obsfuscation - Don't do this.  See black magic.  Or just operate on Kerckhoff's principle aka Shannon's maxim: make the system strong even if the enemy perfectly knows the system.  Obfuscation/black magic can be overcome with a little analysis and provides some security (defense-in-depth), but not much.  However, a strong key-strengthened cryptographic hash with a high-entropy initial passphrase/password can easily be built to have a computational complexity that is completely unfeasible to attack with all the computers in the universe for thousands of years, without major advances in computer science (e.g., quantum computer or breaking the hash function).

  In the end whatever is done with the password it will not prevent someone using a stupid password (like 'password' or '123')

Actually I'll disagree on this one.  Depending on how captive the audience is (e.g., workers must use it for their job), you could invalidate simple passwords whenever a new password is setup (e.g., check against a leaked password list of a ~million common passwords and invalidate all matches, or doesn't pass other minimum standards: must be 8+ characters with upper/lower/number/symbol or a 20+ character passphrase).  Basically, if its a secure application that has serious repercussions for your end if an account is breached, something like this is a great idea.

Granted users will have negative user experience if you are too strict (so if you are a simple web app or an online retailer that wants lots of users and doesn't really worry about accounts being stolen from weak passwords, you probably do not want to implement strict password rules; but the retailer should do things like require re-entering credit card information after the email/shipping address changes and should send an receipt email after all purchases).  Also, beware this ultimately weakening security by users posting the password on their monitor in a common work environment; so make it clear that there are consequences to a user's account being breached.


Methods to Prove Data Authenticity from Potentially Compromised Sources? I've been thinking about this problem for some time and I wanted to ask if there are any known methods, or research papers, about how to prove "authenticity" or correctness of data originating from a potentially compromised source (remote server, process, etc). Specifically what I've been imagining is say you have service A and service B, service B sources data from A but is worried that A has been compromised such that even if data is signed by A, B can't trust that it was generated by code written by A's developers. Is it possible for B to prove to itself that data from A is authentic, that it was indeed generated by the expected code and not injected or generated by an attacker who has compromised A?
One solution I've been thinking about is using a sort of distributed ledger or blockchain so that multiple nodes compute the same data, and in doing so raises the bar such that an attacker would have to compromise N% of the services producing the needed data, this provides naturally replication and I can use an appropriate consensus protocol, but ofc introduces some overhead, efficiency concerns, and I would need to think hard about side-effects being performed more than once.
If there is only one node possible of generating data, such as a sensor node, and it is compromised, I'd imagine all hope is lost, but I also wouldn't be surprised if there is some clever crypto scheme that attempts to solve this problem as well.
I hope it's clear as to what the question is, thank you.
Edit:
After some research I stumbled upon two crytoschemes that seem to attempt to address the problem:

Secure Multiparty Computation (SMC). I found a thesis paper Implementation of a Secure Multiparty Computation Protocol and the author says

In typical use cases of SMC, parties involved are mutually distrustful, butone can also imagine the case of multiple machines owned by a single party, performingSMC to collectively decrypt and process confidential data. No single machine would havethe key, and no single machine would see the plaintext.  Now it would not be enough forthe APT to compromise a single machine holding the decryption key, but every single oneof the machines would have to be compromised.

This seems almost what I was looking for.

Homomorphic Encryption: This seems to be another cryptoscheme that might be able to achieve a similar goal, except that, if I understand correctly, an attacker could still perform arbitrary operations on encrypted data while not knowing exactly what the data is.

I don't know enough about cryptography to know if these two schemes might one day be a practical option to solve the problem of not trusting service A as described earlier, any insight?
Thanks again.

Solved problem - use signatures but place no value on self-signed data.


Bitlocker, does additional authentication at startup with TPM device provide any extra security? Will enabling additional authentication on startup provide any extra security with Bitlocker? At the moment, my laptop boots straight into a Windows login where I use a pin. If I chose to not use pin, and a complex password, would that provide the same level of security as authentication at startup?

Thanks,

Operating system authentication never provides the same level of security than a power-on password. If the TPM gives the encryption key at startup without extra authentication, it's vulnerable against

cold boot attacks

  Problem is that that means that the machine can always be booted up to
  a state where it has encryption keys in memory where they can be
  stolen using a cold boot attack. - -

  None of these mitigations help if you have removable RAM. Then you can
  do the original cold boot attack from 2008.

Direct Memory Access (DMA) attacks (Firewire, Thunderbolt, PCI, PCCARD...)

  An attacker may be able to search for
  BitLocker encryption keys in system memory by spoofing the SBP-2
  hardware ID by using an attacking device that is plugged into a 1394
  port. Alternatively, an active Thunderbolt port also provides access
  to system memory - -

and sniffing Low Pin Count (LPC) bus.

  As the decryption happens automatically, if we can sniff the VMK as
  its being returned by the TPM then we can enter that information into
  any number of BitLocker libraries and decrypt the drive. - -

  TPM2.0 devices support command and response parameter encryption,
  which would prevent the sniffing attacks. Windows doesn’t configure
  this though, so the same attack a TPM1.2 device works against TPM2.0
  devices.

Therefore, Microsoft recommends using TPM+PIN and disabling standby mode i.e. always shutdown or hibernate.


RSA signature security with short keys RSA keys with the size of 1024 aren’t considered to be safe anymore. Does this also apply if you use this key for signing only? Can a signature be faked easily with a short key length?

When RSA keys are too small, the private key can be derived from the public key. This means the attacker doesn't even need to have access to a signature created by the private key, all he needs is the public key. It doesn't matter if the key is used for encryption, signatures, both, or nothing at all.

The current largest RSA key known to be broken is 768 bits, but governments and organizations with large amounts of computing power may be able to factor a 1024 bit key in the near future (perhaps even today), so 2048 bit keys are generally recommended now.


Is it safe to use the Keccak Algorithm to create the Key for a Serpent cipher? I like to store some configuration but would encrypt them with the Serpent cipher.
Is it safe to do this? When not, what is a better solution?

You don't create a key with a hash function. You create a key with randomness. Or, maybe, you derive a key from another secret value, using a Key Derivation Function.

A symmetric encryption algorithm is normally defined to accept "binary keys": any sequence of bits of some specific size is acceptable as a key value. When an encryption algorithm accepts a binary key, then any secure KDF which outputs such unbiased sequences of bits can be used to produce the key.

I suspect that you are trying to do password-based encryption: to derive a key from a password, and then use the key with a symmetric encryption algorithm. If that is the case, then do yourself a favour: use an existing protocol/format, don't try to design one yourself. These things are subtle. Nobody really knows how to make a secure protocol from the first try, or at least make sure that what they designed is secure (it cannot be tested). So the smart thing to do is to use something which has already been designed and heavily reviewed by lots of other people. I suggest OpenPGP.

Even better, if you use a standard format, then you may hope to use an already existing library which does all the job for you. It so happens that writing a secure implementation, even starting from a standard protocol, is also very hard. Code which is easiest to write properly is code which has already been written properly. In the case of OpenPGP, this points to GnuPG. Or BouncyCastle if you work with Java.


Are Javascript closures a useful technique to limit exposing data to XSS? I'm wondering if using Javascript closures is a useful technique to limit exposing data to XSS? I realize it wouldn't prevent an attack, but would it reliably make an attack more difficult to execute, or would it only make my code more irritating to write and read (a waste of time)?
I got the idea from the Auth0 documentation regarding storing OAuth/OIDC tokens. It reads:

Auth0 recommends storing tokens in browser memory as the most secure option. Using Web Workers to handle the transmission and storage of tokens is the best way to protect the tokens, as Web Workers run in a separate global scope than the rest of the application. Use Auth0 SPA SDK whose default storage option is in-memory storage leveraging Web Workers.
If you cannot use Web Workers, Auth0 recommends as an alternative that you use JavaScript closures to emulate private methods.

I can see how this is better than just putting the token or other sensitive information in localstorage. In localstorage an XSS attack needs only to execute localStorage.token to get the token.
Now, if you're not familiar with tokens just apply this reasoning to any sensitive to information. In my case I want to build a client-side cache mapping user IDs to usernames for an administrative interface, but I realize that client IDs and usernames are somewhat sensitive, so I wondered if I could "hide" the data.

The goal here is to keep the token secret, even if an attacker exploits an XSS vulnerability - sort or like emulating the HTTP-only flag for cookies, in other words. I guess the closure would be a function that calls the API for you, using the token for authentication, and then return the result of the API call. In that way, you never have to touch the token.
Using closures would offer only a partial protection for a number of reasons:

There are lots of other powerful things an attacker can do with XSS. Like stealing the victims password through keylogging.
Even if you can't get the token, you can still make calls to the backend with it through the closure. So maybe not permanent access, but temporarey access.
You can probably still steal the token in some clever way.

My best bet would be to add a service worker that proxies any request to the API and picks it out of them. Not sure this is possible, but I would think so.
If the closure allows the caller to specify the URL of the API, just make the calls to evil.com...
The token has to get into the closure somehow. Is it hardcoded into the JS code? Grab it with element.innerHTML on the script tag. If not, steal it before it gets into the closure. This may or may not be possible, depending on the set up and the nature of the XSS vulnerability.

Since the protection is so limited, I would not spend a lot of effort on this. Especially, I would not write convoluted and complicated code just to achieve this. But closures can be a good thing for code quality, so if they fit with your code style by all means do use them.


Protecting encryption of outdated software with a server I have a 1st generation iPad, and I usually use it for web browsing when I'm home. The 1st gen iPad can't run newer versions of iOS (I'm stuck with iOS 5). I went to a website that tells if your SSL client is good or bad. My iPad has a bad SSL client. I have a computer that I use as a personal home server. The server has a good SSL client. I was wondering if I could connect my iPad to that server, and then the server would encrypt the connections for me. What I want to do is to use the computer as something like a proxy server, and the connections between the iPad and my proxy could be unsafe, because I trust my home network, but the connection between the proxy and the web would be safely encrypted. I tried using the Squidman proxy server, but I went to that website again and it told me that the SSL client was bad. So I think that perhaps the Squidman proxy server doesn't do the whole encryption process, and it leaves this job for the iPad SSL client, which is bad. How could I have a proxy server that handles the SSL encryption?

Essentially, you're looking to conduct a man-in-the-middle attack against yourself.  Squid newer than 3.1 offers a feature called sslbump that can perform this technique, where connections are decrypted then re-encrypted.  You can use dynamic certificate generation to make certificates that match the hostname correctly, but you'll need to install the Certificate Authority from Squid on your iPad.

Now that I've answered your question, I'll go for the intent -- you're trying to make yourself more secure, but I'm not convinced you are.  Did the SSL test site list specific attacks that your client is vulnerable to?  What threats are you concerned about?  Keep in mind that by proxying your connection, you're adding more complexity, and thus more attack surface, to your setup.  If your proxy server gets compromised, then 100% of your traffic will be readable by the attacker.  Also, you'll get no benefit from this setup if your iPad is not on your home network.


How secure is this process for creating passwords? I've been research into how to be as secure as possible when it comes to password security for online services and websites. Obviously there are some big no no's like using dictionary words, using the same password for multiple websites, personal information, etc.

I've looked into password managers and they seem like a pretty good idea, but also am a little skeptical on the security of password managers also.

I'm leaning towards having a strong unique passwords for different sites that I can remember, which is virtually impossible to remember if you were to have them almost entirely unique.

How secure is this process? If I were to for example have a base password of something around the lines of I^l@t(h$Y1G2  (Don't worry, not what I'm actually using)

I would use this base password for all of my passwords, but to make each unique I would do something around the lines of placing the first vowel of the website name at the front and the first consonant at the end.

So my theoretical password for Twitter.com would be iI^l@t(h$Y1G2T

How secure is using this type of system?

On a practical basis, I'm going to have to say that this type of system is extremely weak once any one of your passwords has leaked; it doesn't matter which one.

For example, if you used }P_-^cWi_OD~w{qjjA4f (randomly generated) as your "core" password, then you'd have

o}P_-^cWi_OD~w{qjjA4fN for NotSecureSite.

and a}P_-^cWi_OD~w{qjjA4fB for BankSite.

Assuming

Your NotSecureSite password gets found out by an attacker somehow, perhaps because they are a Plain Text Offender and suffer a breach

a. And then those plaintext passwords make their way out, as the RockYou and Facebook lists did
Then another site you're on suffers a breach; we'll say it was BankSite, which used MD5 hashing (for simplicity; really, they could use anything, even fairly reasonable algorithms)
An attacker with both sets of data who uses the following simple rule will find your Paypal password using John the Ripper or oclHashcat and the following simple rule:

a. Command line:

./oclHashcat64.bin --hash-type=0 --attack-mode=0 --rules-file=random.rule random.word.md5 random.dict

a. One line in random.rule reads

[]^a$B

a. [ - delete first character
a. ] - delete last character
a. ^ - prepend the next character
a. $ - append the next character
a. Note that there are only 3,844 rules to exhaustively search the space for each starting password if the attacker goes through a-zA-Z0-9 for both; your actual scheme can usually be found in 130 rules (5*26) for each password.

Worse, this is pretty tiny.  Rulesets distributed with oclHashcat by default include the 12 thousand rules of T0XlCv1.rule, the 35 thousand rules of d3ad0ne.rule, and the 123 thousand rules of dive.rule, so less than 4 thousand maximum is a drop in the bucket.

Try using unique cryptographically random, long passwords and a password manager like KeePass to generate and store them; it has ports for Apple, iPhone, Android, Linux, Windows, etc.

Make sure to go into Database Settings, Security, and set the number of rounds to at least one second's worth, preferably several (there's a button/link for 1 second delay; then make it bigger) particularly on slower devices.

As an alternative, I would suggest something very different.  It can be done in many ways, but using any of the variety of PBKDF2 implementations on my github site, several of which include Windows executables, some of which are in Python or other common languages.

Then, use your "core" password as the password, the website name as the salt, a lot of iterations, since you have no or almost no special characters, you'll need even longer passwords than normal, but you'll be able to cut and paste.  At this time I apologize, as Base64 output isn't implemented much yet, though I'm working on it.  hex output is fine, though, if you use all of it and -o parameter, output length, is long enough - just know hex is twice as long.

NotSecureSite:

./pbkdf2 -p a}P_-^cWi_OD~w{qjjA4fB -s NotSecureSite.com -a SHA-512 -i 1024000 -o 20

104d58f4c9fac5063ed9ed9303ccadc740053963

./pbkdf2 -p a}P_-^cWi_OD~w{qjjA4fB -s NotSecureSite.com -a SHA-512 -i 1024000 -o 20 -O base64

EE1Y9Mn6xQY+2e2TA8ytx0AFOWM

BankSite:

./pbkdf2 -p a}P_-^cWi_OD~w{qjjA4fB -s BankSite.com -a SHA-512 -i 1024000 -o 20

acaafd556c984e1c225369a5b95e37a38e34e48f

./pbkdf2 -p a}P_-^cWi_OD~w{qjjA4fB -s BankSite.com -a SHA-512 -i 1024000 -o 20 -O base64

rKr9VWyYThwiU2mluV43o4405I8

The longer hex and shorter Base64 are exactly as secure, since they came from the same 20 binary bits.
both the base password and the number of iterations must be the same
note that the NotSecureSite and BankSite passwords look nothing alike, and have no discernable patterns beyond being clearly hex or Base64 encoded data.
note that I used more than a million iterations AND a 20 character random base password; this should help protect against those who have determined your algorithm (since we must assume attackers figured it out/learned of it somehow) by giving a large keyspace and slowing them down.


How to tell JohnTheRipper to solve a password using multiple hashes? I have 6 archive files in 7zip format. They have the same password. I use the perl script 7z2john to generate a hash for each of the archives.

I try to combine the hashes into a hashes file, then pass it to john. Is it possible to tell john the hashes representing the same password?

$ ./JohnTheRipper/run/john combined.hashes --session=COMBINED
Warning: detected hash type "7z", but the string is also recognized as "7z-opencl"
Use the "--format=7z-opencl" option to force loading these as that type instead
Using default input encoding: UTF-8
Loaded 6 password hashes with 6 different salts (7z, 7-Zip [SHA256 256/256 AVX2 8x AES])
Cost 1 (iteration count) is 524288 for all loaded hashes
Loaded hashes with cost 2 (padding size) varying from 0 to 8
Loaded hashes with cost 3 (compression type) varying from 0 to 1
Will run 8 OpenMP threads
Press 'q' or Ctrl-C to abort, almost any other key for status

I hope the password could be solved easier than just 1 hash (or it's just my imagination?).

I tried to solve the password using 1 hash, but john spent more than 120 days to crack, still no luck.

It is not possible to combine multiple hashes in order to speed up a brute-force attack. In your case the hashes seem to use the same algorithm, which means it doesn't matter which hash you try to crack.


Explain the Heartbleed Python code first post here so be gentle please!

I understand the Heartbleed vulnerability concept, and I have a general grasp of Python. I'm struggling to understand the PoC Python code though, so was after a bit of code dissection :)

Particularly the two sections where it defines the 'hello' and'hb' message? I watched the messages going across the wire in Wireshark and can clearly see the hex going back and forth. Then comparing this to a normal SSL connection it's fairly similar.

So I'm guessing the content of that hex is setting up the SSL connection and heartbeat request? But can anyone explain the hex involved, or more specifically what this is derived from?

I've seen the RFC that defines the heartbleed extension, but for some reason I can't translate that into how this hex has been derived. Am I being stupid or just missing something?!

I guess you are referring to ssltest.py that is circulating in the wild. The Client Hello was probably just copied from another packet capture. It is part of the SSL handshake:

  Client                                               Server

  ClientHello                  -------->
                                                  ServerHello
                                                 Certificate*
                                           ServerKeyExchange*
                                          CertificateRequest*
                               <--------      ServerHelloDone
  Certificate*
  ClientKeyExchange
  CertificateVerify*
  [ChangeCipherSpec]
  Finished                     -------->
                                           [ChangeCipherSpec]
                               <--------             Finished
  Application Data             <------->     Application Data

OpenSSL allows heartbeats to be received during the handshake. Because the client has not yet sent a ChangeCipherSpec message, the Heartbeat request is not encrypted. For an explanation of the heartbeat request and response format, see this answer. It also shows why the exploit is happening, the payload length is too large and the payload + padding is omitted.

The format of the SSL packets are described as TLSPlaintext in Appendix A of RFC 5246 (TLS 1.2). The "fragment" would be the ClientHello handshake message and the Heartbeat request starting at the type and payload length.

I think that the comments in my implementation of the Heartbleed server PoC will help you understand it better.


Remote host identification has changed - How do I know if it's an attack or not? When connecting using SSH to a shared hosting provider I'm regularly using, I got this message today:

  WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!
  IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
  Someone could be eavesdropping on you right now (man-in-the-middle attack)!
  It is also possible that the RSA host key has just been changed.
  The fingerprint for the RSA key sent by the remote host [xyz.example.com]:2222 is
  2b:6b:ec:d3:c0:fe:fb:40:11:fe:4b:73:03:17:6b:89.
  Please contact your system administrator.
  Add correct host key in C:\Users\Example.ssh\known_hosts to get rid of this message.
  Do you want to delete the old key and insert the new key?

I clicked "No", because I have no idea if it's a legitimate change or an actual attack.

How would I find out? The hosting provider is using CPanel, if it helps.

Clarification due to "possible duplicate"

I've seen many similar questions asked here and on StackOverflow, but all of the answers seem to explain how to make the "annoying" warning go away, not how to actually make sure that you're not connecting to a man in the middle. If I wanted to make it go away, I could just click "OK".

I'm asking "How do I know if it's an attack or a legitimate change?", not "How do I make the warning go away?".

You did the right thing, don't connect if you don't know what happened, that is exactly what the warning is for. This message would absolutely appear if an attack was taking place. If it wasn't it could also appear if something else has changed.

You need to investigate what caused the change before drawing a conclusion.

If you can login in an alternative way (i.e. via cpanel?) check the SSH daemon configuration for the keys it is using [/etc/ssh/ssh_host_*], the configuration could have changed and the order of the host keys presented could have changed, thus showing a different one, check the date of change of host key files, try to find the fingerprint of the stored key files and compare to the value you have, etc.  Has the IP address changed since you last connected?

Try to connect to the host using a completely different network (e.g. tethered to a smartphone as opposed to using the local wifi?), see if the same happens.


Seeding a C# random number generator securely I'm trying to figure out the best way to securely seed a rng in C#.

The class I am currently using is the Random class

https://msdn.microsoft.com/en-us/library/system.random(v=vs.110).aspx#Same

After going through the documentation you can seed it using an Int32, however and I may be wrong in how i assume this, an Int32 would essentially have only 32 bits of entropy which is much less than the recommended 128 or 256 bits of entropy.

Does anybody know of a better C# RNG or how to property and securely seed it with 128 bits on entropy? I haven't been able to find anything

Thanks for all the help.

EDIT

I'm trying to securely generate random numbers that can repeatable across different machines. Basically I'm trying to find a CSRNG that can be seeded with a hash value or something similar and if I ran that piece of software on a different machine with that hash as the seed, it would produce the same numbers.

To generate a secure random number in .Net you should use system.security.cryptography.rngcryptoserviceprovider instead of system.random

The documentation for it is here:

https://msdn.microsoft.com/en-us/library/system.security.cryptography.rngcryptoserviceprovider(v=vs.110).aspx

In case of link rot, here is the C# sample that Microsoft provide on that link. The random generation is done using the GetBytes method.

//The following sample uses the Cryptography class to simulate the roll of a dice.

using System;
using System.IO;
using System.Text;
using System.Security.Cryptography;

class RNGCSP
{
    private static RNGCryptoServiceProvider rngCsp = new RNGCryptoServiceProvider();
    // Main method.
    public static void Main()
    {
        const int totalRolls = 25000;
        int[] results = new int[6];

        // Roll the dice 25000 times and display
        // the results to the console.
        for (int x = 0; x < totalRolls; x++)
        {
            byte roll = RollDice((byte)results.Length);
            results[roll - 1]++;
        }
        for (int i = 0; i < results.Length; ++i)
        {
            Console.WriteLine("{0}: {1} ({2:p1})", i + 1, results[i], (double)results[i] / (double)totalRolls);
        }
        rngCsp.Dispose();
        Console.ReadLine();
    }

    // This method simulates a roll of the dice. The input parameter is the
    // number of sides of the dice.

    public static byte RollDice(byte numberSides)
    {
        if (numberSides <= 0)
            throw new ArgumentOutOfRangeException("numberSides");

        // Create a byte array to hold the random value.
        byte[] randomNumber = new byte[1];
        do
        {
            // Fill the array with a random value.
            rngCsp.GetBytes(randomNumber);
        }
        while (!IsFairRoll(randomNumber[0], numberSides));
        // Return the random number mod the number
        // of sides.  The possible values are zero-
        // based, so we add one.
        return (byte)((randomNumber[0] % numberSides) + 1);
    }

    private static bool IsFairRoll(byte roll, byte numSides)
    {
        // There are MaxValue / numSides full sets of numbers that can come up
        // in a single byte.  For instance, if we have a 6 sided die, there are
        // 42 full sets of 1-6 that come up.  The 43rd set is incomplete.
        int fullSetsOfValues = Byte.MaxValue / numSides;

        // If the roll is within this range of fair values, then we let it continue.
        // In the 6 sided die case, a roll between 0 and 251 is allowed.  (We use
        // < rather than <= since the = portion allows through an extra 0 value).
        // 252 through 255 would provide an extra 0, 1, 2, 3 so they are not fair
        // to use.
        return roll < numSides * fullSetsOfValues;
    }
}


explanation of an nmap behaviour I'm testing some vulnerabilities on a machine which has the port 22333 opened (it's used as the ssh port, and I can connect to it without any problem and the telned command get connected):

$ telnet  x.x.x.x 22333
Trying x.x.x.x...
Connected to x.x.x.x.
Escape character is '^]'.
SSH-2.0-OpenSSH_6.0p1 Debian-4+deb7u2

But when I use nmap against that machine, it doesn't detect that port to be listened to:

$ sudo nmap -p 22000-23000 -sT x.x.x.x
Starting Nmap 6.00 ( http://nmap.org ) at 2015-06-03 19:54 CEST
Nmap scan report for x.x.x.x
Host is up (0.00014s latency).
All 1001 scanned ports on x.x.x.x are filtered
Nmap done: 1 IP address (1 host up) scanned in 21.50 seconds

Any clue about why nmap doesn't detect the port 22333?

Which version of nmap are you using?

Run

nmap --version

to find out.

If the version in your repository is outdated you can grab the sources and compile them on your own:

$ tar zxvf nmap_6.47.tgz
$ cd nmap_6.47
$ make
# make install

You can also increase the verbosity level by setting the -v [1..6] flag in order to get a better view of what nmap is doing. For example:

nmap -sT -p 22000-23000 -v 6 x.x.x.x


Is it noticeable when you take a copy of a website? Is it noticeable when you use a tool to take a copy of a website? - how likely are you to trigger logs and whatnot when you use tools like HTTrack?

Is it actually illegal or 'bad' to do this? - alls you're doing is browsing the website quite quickly, no?

Is it noticeable?  Very much so: hundreds or thousands of rapid-fire requests from a single address will stick out in the logs, and may trigger anti-DoS or anti-crawler measures.

Is it bad?  Depends on the site, the rate of copying, and many other factors.  Rapidly crawling a website hosted on someone's home server could easily overload their connection and make the site unavailable for other people; if it's  dynamically-generated site on shared hosting, the same could happen due to CPU overload.

On the legal side, it depends on the site's terms of service and what you intend to do with your copy.  If you are simply copying the site for personal offline use and the ToS doesn't explicitly forbid this, it's unlikely that there will be any problems.


Safely load a pickle file? In our Python app, we are using pickle.load to load a file named perceptron.pkl. A HP Fortify static scan raises a high vulnerability, "Dynamic Code Evaluation - Unsafe Pickle Deserialization", at the same line.

How can I remediate this? Is there any way we can safely load a pickle?

The Python manual comes with a warning about the pickle module:

  Warning The pickle module is not secure against erroneous or maliciously constructed data. Never unpickle data received from an untrusted or unauthenticated source.

This warning should be taken very seriously. If you unpickle untrusted data, an attacker will be able to exectue arbitrary code on your system. That is bad. Very bad.

The key part of the quote here is "untrusted or unauthenticated source", though. If you are just loading a static file that you trust no malicious actor would have control over, unpickling is safe. For instance, if you store the file together with your source code and with the same access restrictions, an attacker could just as well modify the source code as the pickle file. So the unpickling does not have to be a security risk.

What if you can't trust the file? You have two options:

Switch to a format not vulnerable to code execution, such as JSON.
Create a restricted unpickler using the find_class method (see the manual).

My guess is that #2 would probably be quicker to implement as it requires less changes in your code. But it is also a risky strategy, as I suspect that it is very easy to make a minor mistake opening you up to a vulnerability. If you want to minimize the risk, I would go with #1.


How to encrypt data with a one time password? We can generate OTP using HOTP - RFC 4226 and TOTP - RFC 6238.

But the generated OTP normally has a checking function authenticator.check(token, secret);. But this only checks if the OTP is valid.

How to store any data such that it will be encrypted in the storage of the system and can only be accessed after entering the OTP.

OTP is not made for that. OTP is used as a second factor authentication to avoid a leaked password compromising the whole account, and is usually rate-limited, and usually locks itself during a small interval if mismatched (I've seen one minute lock after 3 errors). That is the main usage for OTP.

Encrypting with OTP does not make sense. As the token you enter is usually 4-8 digits long, bruteforcing it will be trivial. You cannot rate-limit a decryption routine, so nothing stops an attacker to try every possible digit very, very fast.

Even if you create a system that protects the key somehow, an attacker can tamper with the clock and send all possible combinations.


What do you call an antivirus that detects suspicious activity? A traditional antivirus scans data at rest and data in transit for known virus signatures. (Where "virus" includes trojans, rootkits, et al.)

This does not help when defending against zero-days and active intrusions. By definition they have no known signature. What do you call an antivirus that instead responds to suspicious activity (rather than known signatures)?

The traditional technique described sounds like a signature- and host-based intrusion detection system. (IDS is a broad term that includes antivirus software.)

Some systems detect known patterns of bad behaviour, in addition to known bad data. These pattern definitions are not dynamic, so you might still consider them to be "signatures". In consumer antiviruses this feature is sometimes included under the umbrella term "real-time protection".

A dynamic (non-signature) implementation would be called an anomaly-based IDS. This relies on machine learning to generate heuristics that are used to detect suspicious behaviour.


Strange GET requests to my Apache Web Server? A few days ago, my Apache web server was hit with get requests, many of which had strange escape sequences. Can someone read the following sample log entries and explain what the person tried to do, and what measures can be taken to protect against this? Nothing was hacked yet, but I would still like to know the purpose of this.

Note that the source IP address and timestamps were intentionally obscured.

1.1.1.1 - - [19/Jun/2013:03:02:01 -0800] "GET /signin.php\vZ\xae\t\xc1\xc8\xb9\x8d\xbd\xb4\xbd\xa9\x85\xd9\x85\xcd\x8d\xc9\xa5\xc1\xd0\xbd\x91\x91}\xb5\x95\xb9\xd4\xb9\xa9\xcc HTTP/1.1" 200 16174 "-" "Mozilla/5.0 (Windows; U; Windows NT 6.1; rv:11.0) Gecko/20100101 Firefox/11.0" "-"
1.1.1.1 - - [19/Jun/2013:03:02:01 -0800] "GET /sig\xb2,\xde HTTP/1.1" 404 10139 "-" "Mozilla/5.0 (Windows; U; Windows NT 6.1; rv:11.0) Gecko/20100101 Firefox/11.0" "-"
1.1.1.1 - - [19/Jun/2013:03:02:01 -0800] "GET /images/q2.gie\xa7\xb1\xb7\xf7, HTTP/1.1" 404 10175 "-" "Mozilla/5.0 (Windows; U; Windows NT 6.1; rv:11.0) Gecko/20100101 Firefox/11.0" "-"
1.1.1.1 - - [19/Jun/2013:03:02:01 -0800] "GET /images/q2.gie\xa2vices-search HTTP/1.1" 404 10175 "-" "Mozilla/5.0 (Windows; U; Windows NT 6.1; rv:11.0) Gecko/20100101 Firefox/11.0" "-"
1.1.1.1 - - [19/Jun/2013:03:02:01 -0800] "GET /m\xae\xe7 HTTP/1.1" 404 9145 "-" "Mozilla/5.0 (Windows; U; Windows NT 6.1; rv:11.0) Gecko/20100101 Firefox/11.0" "-"
1.1.1.1 - - [19/Jun/2013:03:02:01 -0800] "GET /images/z.gif0\x89\xdba\xeb\xbe HTTP/1.1" 404 9199 "-" "Mozilla/5.0 (Windows; U; Windows NT 6.1; rv:11.0) Gecko/20100101 Firefox/11.0" "-"

Thanks.

This looks like typical fingerprinting scans. Some tools send out odd requests to determine the type of server and firewalls you might have in place.

Try to replay those requests to see how your site responds and determine if there are changes you need to make to your environment to make it fail gracefully and consistently, if possible.

It is 'just' a probe, but I would put that IP on a watch list for further activity.


Isn't it almost always not helpful to just change the password of a container after a leak? Let's assume, an attacker gains access to an encrypted container with a weak password. They start a brute-force attack and I assume they will succeed. To protect any content which has been added to the container after the leak, I decide to change to a stronger password.

However, at this point, it doesn't make sense to just change the password of the container, right? Won't I have to reencrypt everything since the attacker can extract the "master key" of the container which won't change with a password change?

This is correct and to some extent applyes even if the container is not leaked yet. If there is any way the attacker may be able to get to the old version of the container (or just its header) for example if you have backups or ssd with wear leveling, it is better to reencrypt.


How to translate "openssl enc" command to nodejs crypto api I have been successfully using openssl to encrypt a large file. I'm trying to develop the equivalent nodejs crypto API code for the following openssl commands:

    openssl rand -hex 64 -out {keyfile}
    openssl enc -aes-256-cbc -salt -in {infile} -out {outfile} -pass file:{keyfile}

So far, I think this is what I need to do:

    const crypto=require('crypto');

    var iv = crypto.randomBytes(16);  // ????

    const encryptionkey = crypto.randomBytes( 32 );
    crypto.createCipheriv( 'aes-256-cbc', encryptionkey, iv );

createCipheriv requires an initialization vector, but my original openssl command doesn't use one.

What value for iv should I use to achieve the same result as my openssl command?

OpenSSL commandline enc does password-based encryption (PBE) by default. This means the key, and IV if applicable which it is for CBC, is derived from the 'password' input by a Password-Based Key Derivation Function (PBKDF); the key is NOT the same as the input. And it uses a particularly poor PBKDF; for details see my attempt at a canonical. Further, the default hash in the PBKDF has changed, and you don't specify which OpenSSL release you use(d) -- but the rand command you posted is an invalid form that was accidentally accepted by the old ad-hoc command parser and is rejected by the standardized parser in 1.1.0 up, so your release must be one that used MD5 for the enc PBKDF.

Incidentally this means most of the entropy in your rand 64 was wasted; the MD5-based PBKDF cuts the entropy to 128 bits (or very slightly less, for technical reasons), and the extra cost of using AES-256 instead of AES-128 also is wasted and doesn't add anything to security. Using 1.1.0 up, or specifying -md sha256, would avoid this specific problem, although there is really no point in using PBKDF/PBE at all for a fully random 'password'.

It happens that nodejs' older (and deprecated) crypto.createCipher (NOT createCipheriv) uses almost the same poor PBKDF as older OpenSSL enc: EVP_BytesToKey with MD5 and 1 iteration, but with no salt, which differs from the OpenSSL default and makes the PBKDF even weaker -- but that doesn't matter for a random 'password'.

If you want or need to be compatible with exactly that openssl enc command, you'll have to code the equivalent of EVP_BytesToKey (for 1 iteration, which is fairly easy), and use createCipheriv with the resulting (derived) key and IV, plus write OpenSSL's Salted__ + salt header. See https://stackoverflow.com/questions/50181685/nodejs-createcipheriv-like-openssl for one example.
If it's enough to be compatible with enc -nosalt on older releases (and enc -nosalt -md md5 on all releases), you can just use createCipher with the password, which must be printable chars e.g. hex as you did in your first example.
enc can encrypt and decrypt with 'raw' key and IV, not password-based. Since your key is fully random that's secure. If that is sufficient, just use createCipheriv with a suitable key and IV. If you reuse a key it is vital the IV be unique (for CTR or OFB) and unpredictable (for CBC and CFB) for each use of a key, but if you use a different key every time it doesn't really matter what the IV is and you can even use a constant (such as all-zeros, which is convenient on the enc side). Pass the key and IV in hex to the enc options -K (uppercase!) and -iv. Note OpenSSL can't itself read these from files, like -pass file: or -kfile for a password, but in most Unix shells you can use file contents in an option like

    openssl enc -aes-256-cbc -d -K $(cat key_hex_file) -iv $(cat iv_hex_file)
    # or
    openssl enc -aes-256-cbc -d -K $(xxd -p key_bin_file) -iv $(xxd -p iv_bin_file)
    # (in most cases it is necessary or prudent to doublequote "$(cmd)"
    #  but here the output is _only_ hex chars so not needed if sane IFS)

Meta PS: we have lots of other Qs about nodejs crypto, and about OpenSSL enc, but I couldn't find a good dupe for the combination.


Can I identify a hash function with neural network? Can I use neural network to identify a hash function like sha256? I mean, generate a bunch of hash codes by different hash functions and also labels. Then, feed these codes into a neural network. Will it work?

No. The output of a cryptographic hash function (like SHA256) is indistinguishable from random data. The only feature that'd be useful to a neural network would be the length of the hash -- and you don't need a neural network to tell you that a 256-bit value could be SHA256.


Certificate Hostname Mismatches - Why do they matter? So, I am implementing some X509 certificates in a backend service where we have our own self-signing process to allow different nodes (out of our control) to receive our blessing (as a CA of sorts).

So, my question is, as it pertains to this particular instance, (and in general, really), why would one care about hostname mismatches between the certificate and the host?  A certificate is useless without the private key, so in the event of a private key compromise, isn't it "all over" so to speak, anyway?  Anyone in a position to execute a man in the middle attack would be able to spoof the hostname.  Is there something I'm missing?

Thanks in advance.

It is a problem in the general case.

If I make my own certificate for "polynomial-is-evil.com" and have legitimate ownership of that domain, I could easily get it signed by a CA such as Globalsign. Your browser trusts that CA. I have both the public certificate and private key.

Now let's say I perform a man-in-the-middle against one of your customers. I present them with my own certificate, which is actually for a completely different domain name. If they don't check the host name and reject when it doesn't match, then their SSL implementation is useless.

If DNS queries are spoofed, the only thing that changes is the target IP address. The actual domain name you're attempting to communicate with is still the same, so your SSL implementation should reject the certificate still.

It is always a good idea to implement DNSSEC and certificate pinning to mitigate these kinds of issues, in the general case.

On the other hand, if the only source of trust is your own private CA, then the issue becomes lessened. If they can MitM the traffic, they still can't present you with a valid certificate. The problem becomes serious again, though, if you accept any certificate signed by a 3rd party CA, because at that point they can contact that CA, get a signed cert for any arbitrary domain, and perform MitM with it.


CVE ID year versus disclosure lag A CVE identifier in use is not necessarily public at a given time.  It gets published when or after the vulnerability is published.

Does this mean that the "year" included in the CVE ID can frequently be years older relative to the year of the first public report of the vulnerability (and therefore to when the CVE ID becomes available for CVE search at MITRE)?  Or is there a mechanism to correlate the year with the year of public disclosure within some limits related to public disclosure?

I am NOT refering to examples like CVE-2010-5298 which was assigned or maybe just published in 2014, because the vulnerability itself was in some sense public since 2010, just without any CVE ID.

I am refering to a big hypothetical currently unknown bug that will be filling the headlines throughout 2017 but be labelled CVE-2010-something due to a vendor secretly and knowingly sitting on it for 7 years.

Does this mean that the "year" included in the CVE ID can frequently be years older relative to the year of the first public report of the vulnerability (and therefore to when the CVE ID becomes available for CVE search at MITRE)?

You can search for CVEs as soon as they are assigned. If no details have been published yet, the entry will reflect that:

  ** RESERVED ** This candidate has been reserved by an organization or individual that will use it when announcing a new security problem. When the candidate has been publicized, the details for this candidate will be provided.

  I am refering to a big hypothetical currently unknown bug that will be filling the headlines throughout 2017 but be labelled CVE-2010-something due to a vendor secretly and knowingly sitting on it for 7 years.

Yes, this can happen. The entry to a reserved CVE states:

  Disclaimer: The entry creation date may reflect when the CVE-ID was allocated or reserved, and does not necessarily indicate when this vulnerability was discovered, shared with the affected vendor, publicly disclosed, or updated in CVE.

The entry date is what a CVE ID is based on. The same issue will not receive multiple CVEs (unless an error was made) as it would cause confusion.

Although in practice, if a vendor wants to sit on it, they will not request a CVE. If a researcher requested a CVE, they will likely publish some details if the vendor does not show effort to fix the issue.


Can a device accidentally transmit a Teardrop attack? On reviewing the firewall log on my router (supplied by my fibre provider), I noticed a few curious entries. Several teardrop or derivative attacks, I'd expect to see things like this in the log from public addresses, but these appear to originate from within the network.

I understand what a teardrop attack is - using the fragment offset field to confuse a device during reassembly of tcp packets, thus causing denial of service in vulnerable devices. In this case the firewall appears to have blocked it.

I have a reasonable confidence that none of the devices within my network are compromised, I believe the device that was assigned this IP at the time was actually an android based phone. So, can a device accidentally generate a tcp packet that the firewall could interpret as a teardrop, or this more likely to be a spoofed Ip in the source address?

This is inconclusive.

Because port 3702 is assigned to WS-Discovery :

  Web Services Dynamic Discovery (WS-Discovery) is a technical
  specification that defines a multicast discovery protocol to locate
  services on a local network. It operates over TCP and UDP port 3702
  and uses IP multicast address 239.255.255.250. As the name suggests,
  the actual communication between nodes is done using web services
  standards, notably SOAP-over-UDP.

So it can be anything in the Android(tablet, phone,etc) that make use of WD-Discovery. If you think none of the Android application should talk to any local web services, then you should carry out further investigation, e.g. turn off all application and turn on one by anytime to observe network behavior.


Should an automated vulnerability test actually delete or modify data in production? We hired an outside company to perform a vulnerability test on one of our sites. Within a few hours, we had problems. Entire tables wiped clean. Entire tables deleted. Hundreds of records in other tables gone. Some table data had been modified. This is all in a db running a LIVE, production site.

We have used the company in previous years with no issues. Obviously, the site has massive security holes. But, aside from that, my question/concern is this:

How common is this? I get that no pentester can guarantee they won't jack something up, but I haven't heard of an automated scan actually
deleting/modifying data in the database.
Should I be concerned that the automated software used could actually be malicious (ironically)?

I'm just looking for a little guidance/thoughts/other's experiences on the situation.

1 This is quite uncommon. And when it happens, it is highly undesirable. I know pentesters who've lost customers for a LOT less serious screw ups.

2 yes, definitely. The evidence is there; dropping a table is something you have to be very explicit about.

I would look into the pentest agreement you signed. Any pentest contract should have a clear scope defined, excluding production environments from actions that could impact them.


How important is a mysql password for localhost? We can assume that if an attacker gained access to a web server running mysql that they would be capable of reading the scripts to determine the mysql password.

If mysql only responds on localhost, does it really need a strong password?

Sure, if there was an exploit on the server which allowed an attacker to upload and run PHP files, they could wreak havoc on the database if there wasn't a secure password. However they could still use that PHP file to access the 'real' server scripts, send them to the client, then read the password that way.

I really don't understand the need for a mysql password if it only responds to localhost. Why is it important?

When I say 'no password' I mean leaving it as the default value of 'password' which is probably the first guess for an attacker

A few reasons come to mind:

Firstly, just because a compromised hosting account can read the credentials of one MySQL user doesn't mean they can read another. Imagine you're on a shared host and one of your co-tenants is compromised, you wouldn't want them brute forcing your password.

Secondly, you might use a number of different users with different permissions within your own systems. For example, one user may be read-only which is used for a publicly accessible site, whereas your admin console uses a user with write access. This would possibly prevent privilege escalation for accounts stored within the database if the publicly accessible system gets compromised - assuming they can't brute force your other MySQL password.

Finally, it's not that uncommon to make MySQL accessible externally so tools like MySQL workbench can be used to manage and query it. In this case you obviously want a strong password.


Failure to capture any packets on wlan0 in monitor mode I have read a lot of Q&As that have achieved success in packet captures of Wifi probe requests, which entails capturing IEEE802_11_RADIO (802.11 plus radiotap header) in monitor mode. But I find that I cannot capture any packets at all in monitor mode (though I have no trouble with packet captures in managed mode on a network). I'm sitting right next to my iPhone, on which I am streaming video and sometimes checking for the presence of additional wireless networks.

Shouldn't I at least be picking up on beacons from APs? Can anyone suggest what my roadblock might be?

I've set my wireless card to monitor mode, then run tcpdump:

ifconfig wlan0 down
iwconfig wlan0 mode monitor
ifconfig wlan0 up
tcpdump -fni wlan0              # TCPDUMP

I've also tried using airmon-ng to create a new device on which to attempt a capture:

stop network-manager            # AIRMON-NG WARNS THAT THIS COULD CAUSE PROBLEMS IF NOT KILLED
service avahi-daemon stop       # AIRMON-NG WARNS THAT THIS COULD CAUSE PROBLEMS IF NOT KILLED
killall wpa_supplicant          # AIRMON-NG WARNS THAT THIS COULD CAUSE PROBLEMS IF NOT KILLED
airmon-ng start wlan0           # AIRMON-NG
tcpdump -fni mon0               # TCPDUMP

In the block of commands above, airmon-ng outputs the following:

Interface   Chipset     Driver

wlan0       Unknown     iwlwifi - [phy0]
                (monitor mode enabled on mon0)

tcpdump consistently outputs the following and then nothing (no captures):

tcpdump: WARNING: mon0: no IPv4 address assigned
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on mon0, link-type IEEE802_11_RADIO (802.11 plus radiotap header), capture size 65535 bytes

I'm running:
tcpdump version 4.5.1
libpcap version 1.5.3
Ubuntu 14.04 LTS

I've also tried airodump-ng in order to scan channels 1-12.

As for my hardware, lspci ouputs:

03:00.0 Network controller: Intel Corporation Wireless 7260 (rev 83)
    Subsystem: Intel Corporation Dual Band Wireless-AC 7260
    Flags: bus master, fast devsel, latency 0, IRQ 64
    Memory at f0400000 (64-bit, non-prefetchable) [size=8K]
    Capabilities: [c8] Power Management version 3
    Capabilities: [d0] MSI: Enable+ Count=1/1 Maskable- 64bit+
    Capabilities: [40] Express Endpoint, MSI 00
    Capabilities: [100] Advanced Error Reporting
    Capabilities: [140] Device Serial Number e8-b1-fc-ff-ff-e8-fa-80
    Capabilities: [14c] Latency Tolerance Reporting
    Capabilities: [154] Vendor Specific Information: ID=cafe Rev=1 Len=014 <?>
    Kernel driver in use: iwlwifi

tcpdump will dump all IP packets captured from the network you are currently connected to. According to your explanation and elements, you've made the interface be up but you haven't connected to any Wi-Fi network: no network, no network packet to capture, so no tcpdump output, it's all simple as that.

You must first connect to an Access Point, then you can examine IP activity of other devices connected to the same Access Point as you.

At last, do not confuse tcpdump which will capture clear Network layer packets, with lower-level and wifi dedicated tools like airodump-ng which will allow to capture raw "Wifi" frames as they go on the air (ie. mostly ciphered). However, not all wifi adapters allow this (the chipset being classified as "Unknown" by airmon-ng leaves me quite pessimistic about yours...). It is frequent even on devices already equipped with an internal Wifi adapter (laptops, etc.) to use another external one, generally USB, for Wifi security testing.


ImageMagick < 6.9.3-9 - Multiple Vulnerabilities question Do you know any contain management system or other applications that are affected by the recent ImageMagick exploits? (I have already played with convert tool which is offered on Linux)

I don't think you can get a solid answer for this. But not many are at risk even if they are running at risk versions of ImageMagick.

First one would have to be able to figure out how many PHP applications are live with ImageMagick installed and configured. No major CMS or PHP application requires the ImageMagick library. For image manipulation the GD2 library is the standard go to and the GD lib has been included since PHP 4.2. So if someone is using ImageMagick they would have to install and configure it to work with PHP themself. With applications like Wordpress they would then have to install and enable a plugin to use ImageMagick as well. Typically shared hosts do not install Image Magick with PHP installs either due to it's history of exploits.

Further more the install and usage of ImageMagick is not enough to make it exploitable. For example, most of the image manipulation is done on the back end of a CMS. (Uploading an image and getting different sizes the CMS can use for example.) And if the public front end is doing real time processing they would have to be able to exploit the front end code to attack ImageMagick. So at this point you are looking for 2 exploits. One to exploit the web application that interacts with ImageMagicks PHP APIs and then an exploit in ImageMagick that is possible through ImageMagicks PHP APIs.

The exploit you mentioned in your question is possible through a PHP application if all the moons are aligned. Especially if the filename input is controlled by the front facing user. But basic input sanitation or the PHP application having control over the filename should be enough to stop this attack. The proof of concept (shell.php) does not implement these but the idea of the proof of concept is to see if it is exploitable, not defendable.

So to sum this up: Not many PHP applications or content management systems are likely to be affected.


USB activity monitoring Is there any method or tool which will allow to monitor activity on USB? With activity I mean if you can by any chance see if files like (pdf, jpeg, doc, etc, ...) was copied or opened on USB device.

There are three timestamps normally recorded:

mtime - updated when the file contents change. This is the
"default" file time in most cases.
ctime - updated when the file
or its metadata (owner, permissions) change
atime - updated when
the file is read

For your need you will need atime, so you can open your USB device in terminal:

user@ubuntu:/media/USB-2477$

and run: ls -l --time=atime myfile.pdf

This will return to you when was the last time when you accessed that file. For copying the file I'm not sure if that will be recorded.

Or use stat it has similar function:

 stat --printf="Change %z\nAccess %x\nModify %y\n" myfile.pdf

It will return:

Change 2017-09-27 21:06:23.000000000
Access 2017-09-27 22:04:00.000000000
Modify 2017-08-11 21:36:40.000000000


Says HTTPS website (Apple and Netflix) are not private after opening port 443 Every time I visit apple.com or netflix.com it says that the connection is not private and doesn't allow me to connect to it. I opened port 443 on my modem (as well as ports 8080 and 2222) so I would be able to ssh to my Raspberry Pi at home from the outside (I also use it to test my website on port 8080).

Ports 8080 and 2222 were open for a good 2 weeks and nothing happened to my Raspberry or home network. But just a few days after opening 443 those 2 sites stopped working.

The problem still persisted after closing the ports and disconnecting the Raspberry Pi from the network.

My questions are what are the security risks of opening ports and what can be done in my situation to fix the problem?

This is the certificate for all sites:

The security risks of opening ports are really about the risks of the services running on those ports. It is possible that someone discovered your test website and pwned your computer because your site had weaknesses (assuming that this is the same computer that you are seeing the error).

If this happened, then yes, they could have done anything, and an effect could be certificate errors on HTTPS sites.

In your specific case, because the certs are not legitimate, it looks like you have been pwned.


Prevent hacking with known IP address and router information on Ubuntu 14.04 LTS I’ve had it! It is the second time that a “hacker” (A hacker or should I say thief) has had access to my Ubuntu 14.04 LTS system.

The person that I suspect has had physical access to my pc because he had the keys to my house. After the first time it happened I nuked the drive with Dban and reinstalled Ubuntu 14.04 LTS.

When this happened again I was furious! The only explanation that I can think of is that he has my IP and MAC address through using Ipconfig when he had physical access to my pc and he has the information of my Huawei HG532s router.

I am going to Dban my pc once again and reload Ubuntu 14.04 LTS. How do I prevent someone from using Metasploit against my pc (If they have my IP/MAC address)?

Your MAC and IP address don't help an attacker at all unless they're combined with open ports on your router, and vulnerable listening services on your machine. It's much more likely that it's a password re-use issue or similar. Did you change your machine password and Wi-Fi password? If he knows where you live and knows your WiFi password he can just sit outside and inject payloads into all your internet traffic.


RFI - Is this possible even if you use an Application Server? Since JBoss is acting as a middleware - Application Server - I was wondering if it's still possible to face with File Inclusion attacks.(?) The reason I was wandering so is that in such a case, no request will be directly sent to any Storage or DataBase server since JBoss will be stepping in the middle of communication to check for validity and so on, so I thought RFI/LFI might be already prevented by using Application Servers.

If it's yet possible, what can be done to prevent File Inclusion attacks? - not including making sure that PHP is immune enough from malicious codes

OS : RHEL 7

Application Server : JBoss

It's possible to have a file inclusion attack on JBoss (e.g exploit code: https://www.exploit-db.com/exploits/36553/).

I've tested the Remote Code Execution & had it's instances landed to file inclusions such as the follows:

A more detailed explanation of this could be found at: http://securityxploded.com/JBoss%20Whitepaper.pdf

Since, it's Java Tier; even the middleware could be prone to attacks given in context that File Inclusions (whether remote or local) is caught due to lack of proper sanitisation or validations.

Example code:

<jsp:include page="<%=(String)request.getParameter(\"template\")%>">

The sample code takes a user specified template name and includes it in the JSP page to be rendered. This could be a local file inclusion. However, RCE exists in JBoss & could be easily manipulated to achieve further escalation into file inclusions.


Veracrypt - When using Full OS encryption, isn't it easier to decrypt using the OS file placement? Let say you encrypt A.jpg and B.jpg , B is just after A in the hard drive.

let say A = 0101 B = 1001

on unencrypted HDD : AB = 01011001

once encrypted : AB = 11111011

if someone know A is the first bits and know A = 0101

would it be easier for an attacker to know the password by comparing the data of both encrypted and unencrypted data ?

so in that case, in a fresh install of Windows 7, if I encrypt it,

wouldn't an attacker compare his windows 7's first bits to find a correlation between my windows 7's first bits and find my password ?

(sorry for my English...)

In a properly implemented encryption scheme, comparing the encrypted and unencrypted data does not provide any clues about the password used to encrypt, as you seem to think.

Any high quality Symmetric Encryption algorithm will include an Avalanche Effect so that if even a single bit of the key is wrong, then the entire result will appear random, and therefore not provide any clues. The attacker does not know whether a guessed key is slightly wrong, or completely wrong.

Also note that the Encryption/Decryption Key is actually Derived from the user's Password using a Key Derivation function. The purpose of using a Key Derivation function is to create a fixed-length key (i.e. 128 bit key for an AES-128 encryption) based on a variable length password (i.e. most passwords are less than 128 bits), including its own avalanche effect. Also the Key Derivation function is usually somewhat processor intensive to reduce the amount of Entropy required for a password to be safe from brute force.

(In your example, it seems you have a XOR cipher, which does not include an avalanche effect.)


What advantages and disadvantages do Palo Alto firewalls have, compared to others in the market I am about to start an evaluation process for firewalls. I have experience with Checkpoint and Juniper, but I don't have any information on Palo Alto networks, other than their marketing stuff.

So I would like to hear from IT analysts/network administration the pros and cons of Palo Alto in areas such as:

Ability to identify malicious traffic at speed
Ease of configuration - through management console, individual GUI, command line etc
Remote management functionality
Logging functionality
Does it play well with other vendors' hardware

etc.

My experience with Palo Alto is limited so please take what I say with a grain of salt (and I'm sure people here can correct me as necessary)...

Palo Alto is a completely different firewall paradigm than Check Point, Juniper, or almost any other firewall.  A traditional firewall defines traffic flow based on source IP, destination IP, and port (or IP protocol definition, e.g. ICMP type/code).  Palo Alto defines traffic flow based on data stream content; a TCP flow over port 80 is expected to be HTTP, but it could just as easily be SSH, and in the Palo Alto world you limit connectivity based on semantic content -  you'd block that SSH even though HTTP would get through to the same device.  A Check Point or Juniper would let both through if port 80 was open.  (Yes, I believe Check Point has limited ability to enforce on application protocol if so configured, but that is a tacked-on addition to the traditional IP protocol filtering which is the core of their product.)

The weakness of such an approach is that it hinges on the ability to classify and decode traffic, which is a non-trivial problem.  Go look at any IDS' false positives for evidence of that.  Also, these days, everything can be (and is) wrapped in SSL, complicating protocol analysis.

Some people think Palo Alto does a great job; some people think it isn't good enough.  If you're going to do installations as part of your eval, you can make your own decision on that, I'd be hesitant making that decision for your network based on someone else's experience on their network, since it's a content (and context) sensitive device.

Someone with more experience with Palo Alto could probably draw really useful comparisons to proxy firewall and IDS/IDP products, so perhaps that should be part of your question.


Proving creation time/date of a screenshot I have to produce a screenshot of a web page, and want to make sure others will know without any doubt that this screenshot has been produced today.  That is, I would like to embed today's date in the screenshot as irrefutable proof the screenshot has been made exactly today.

Is there any way?

If you want to prove to others that you took the screenshot on a specific date and not later, you will not be able to do it yourself, you will have to rely on some common trusted third party.

For low importance issues, this can be accomplished by simply posting the image on some well known public service where the date when the image has been posted will be mentioned. Be sure to check beforehand that this service does not offer any possibility to modify the picture without altering the upload date!

For higher importance issues, you will have to contact a bailiff or a notary. By being present during the screenshot, they will be in measure to vouch the date and the conditions when it has been taken. For instance I've read about such procedure being used when someone wants to keep a proof of the existence of a security flaw still valid even once the flaw itself has been corrected. However, if you go that way I would strongly recommend to check the Law StackExchange website before engaging yourself into anything.


Content-Security-Policy suspicious entries in the log I've set up Content-Security-Policy-Report-Only header, and am in report-uri getting relatively high number (several hundred per month) of failed requests on img-src for  suspicious URLs:

https://netanalytics.xyz/metric/
https://netanalitics.space/metric/
https://glganltcs.space

there are also some which look even more hacked:

script-src on https://etgfsiwxsbxr.ru/d6safundjenk6af/29915.js
connect-src on http://gj.track.uc.cn/collect

and even some supposed style accesses for fonts?!

{
    "csp-report": {
        "blocked-uri": "https://fonts.googleapis.com",
        "document-uri": "https://biciklijade.com/",
        "original-policy": "default-src 'none'; manifest-src https://biciklijade.com; script-src https://biciklijade.com; style-src https://biciklijade.com; connect-src https://biciklijade.com; form-action https://biciklijade.com; img-src https://biciklijade.com https://*.tile.openstreetmap.org https://*.tile.osm.org data:; report-uri https://biciklijade.report-uri.com/r/d/csp/reportOnly",
        "violated-directive": "style-src"
    }
}

Note that I at most specify CSS body { font: 16px/21px Arial, "Helvetica Neue", Helvetica, sans-serif; } without ever specifying src to download fonts from google (or anyone else), so IMHO browsers should never be connecting to google to get them, right?

I've checked the code and databases to make sure that they haven't been cracked, and they all look just fine. Browsing the site from Firefox and Chromium with developer console open also does not seem to trigger any CSP violations. The site is mostly hand made and is not supposed to be using any analytics.

Question 1: Do any of those look legitimate to you? They don't to me; and I'd like to move CSP from report-only to real blocking

Question 2: If those are indeed non-legitimate accesses, is it possible they all come from cracked clients, instead of infected website? I've already checked, and website seems clean, but I'd like some reassurances that other people are seeing stuff like that too

Question 1: Do any of those look legitimate to you?

Yes, they seem legitimate. There are high chances that they are due to some browser plugins. Some plugins injects code in the dom which will result in these violation.
It could be possible that your users use such plugins. (I personally found such plugins to be pretty common and used by many)

  I'd like to move CSP from report-only to real blocking

That would be great. However, you must evaluate all scenarios and a proper action in place in case when it's actually happening because of your code. (Or else, the resource will be blocked and the site will not be usable anymore)

I suggest testing all pages and in multiple browsers before changing to block mode.
Also, it would be great if the mode can be changed without much effor. I mean, if runtime you got an issue, then you should be able to do it with negligible downtime.

  Question 2: If those are indeed non-legitimate accesses, is it possible they all come from cracked clients, instead of infected website?

I don't have much experience in this part.

On a side note, you could explore the possibility of supporting for only those clients which support CSP. For others, you can block or just display an error message. (Again, this is specific to your usage. To check this part, you can collect client details for first few weeks/months and then decide whether you should follow such strategy)

  Further Reading

I found Dropbox blog to be really helpful in rolling out a strategy in filtering the reports and moving to block. You might find it useful : Dropbox Blog on CSP


RSA for authentication? Is it possible to use RSA public and private keys to authenticate two computers (or to make sure they're both the right computers)? If so, how?

Thanks!

Yes, it's possible. Computers Alice and Bob both have one private key and one public key each.

Alice chooses a random token and encrypts it with Bob's public key and its own private key. Bob decrypts the token with its private key and Alice's public key, then reencrypts it with Alice's public key.

Upon receiving the original token from Bob, Alice knows that Bob must know Bob's private key, therefore it must be Bob. And since the token was decrypted with Alice's public key, Bob knows that Alice is in possession of Alice's private key, which means it is Alice.

And since nobody else except Alice and Bob are now privy to the random token that has been exchanged, both Alice and Bob may use it as the key to a symmetric cypher algorithm suitable for exchanging further communication (they might also use again RSA, but it's more expensive computationally):

  ALICE = Alice's public key; bob = Bob's private key

  Alice chooses K

  Alice encrypts with BOB,
  then with alice

                   ----> alice(BOB(K)) ---->

                                                Bob knows ALICE and bob,
                                                so can retrieve K
                   <---- bob(ALICE(K)) <----
                      (or just ALICE(K))
              (or even K, if K need not be secret)

  Alice gets confirmation

                   <---- AES256(K, MESSAGE[0]) ---->
                   <---- AES256(K, MESSAGE[1]) ---->
                   ...
                   <---- AES256(K, MESSAGE[N]) ---->

During such a conversation, K may also get refreshed from time to time.

Real life example (well, sort of)

In this example Alice and Bob are two friends and they both have the OpenSSL utility. They communicate through a public channel (e.g. their Facebook pages) where they can post binary files. OpenSSL actually can produce ASCII files that would be much better for this purpose, but let's keep as near the above as possible (in real real life we'd use some OpenSSL scripts that would automate the whole thing and work much better, or some tool that would wrap OpenSSL to do the same things with an easier interface).

There are some caveats that I'll mark with "VULN". See at bottom.

To begin with, Alice creates a RSA public/private key pair and extracts the public key. Bob does the same (his files will be named bob-*) (VULN-1).

openssl genrsa -out alice-both.pem 1024

openssl rsa -in alice-both.pem -out alice-public.pem -outform PEM -pubout

Now both Alice and Bob publish their public keys on their facebook page. Anyone can read them.

Now Alice wants to exchange a private conversation with Bob, maybe some files. Alice wants to be sure that Bob is cognizant of their source, and she wants Bob the be the only one to be able to read the files.

This can be done using asymmetric encryption only, but it would be too slow and inefficient due to size constraints and computational overhead. So they need to use symmetric encryption, and for this, a shared secret (above, this was called K), that only they know.

They do so by choosing a K, and communicating it over a secure channel. The secure channel is provided by asymmetric encryption over a public channel (facebook).

Bob being a gentleman, it's Alice who chooses a passphrase.

She does so by creating a text file with the passphrase...

echo 'the magic words are Squeamish Ossifrage' > phrase.txt

and encrypting it with Bob's public key downloaded from Bob's facebook page (VULN-2)

    openssl rsautl -encrypt -inkey bob-public.pem -pubin -in phrase.txt -out file1

Now, only Bob can decrypt the file. The problem remains how to make Bob sure that this is from Alice. Alice could cut "file1" in pieces small enough to be encrypted and send them all, but it's not necessary; she can sign the file with her private key.

    openssl dgst -sha256 -sign alice-both.pem -out file1.sign file1

Now Bob receives the two files. He first verifies the signature against Alice's public key (VULN-2 again).

    openssl dgst -sha256  -verify  alice-public.pem -signature file1.sign file1

and he gets "Verified OK" (if anyone else's certificate had been used, for example his one, he would have gotten "Verification Failure").

So, verified against the key published on Alice's facebook page, the "file1" is at least as trustworthy as Alice's facebook account.

Bob proceeds in decrypting with his own private key.

openssl rsautl -decrypt -inkey bob-both.pem -in file1 -out secret

Now Bob knows the secret phrase (it's in "secret") and can encrypt a document using that phrase.

openssl enc -in secret-document.txt -out secret.bin -e -aes256 -k "$( cat secret )"

or, equivalently,

openssl enc -in secret-document.txt -out secret.bin -e -aes256 -k "the magic words are Squeamish Ossifrage"

secret.bin is again posted publicly on Bob's page.

Alice on the other hand just runs the corresponding decoding command

openssl enc -in secret.bin -out plain.txt -d -aes256 -k "$( cat phrase.txt )"

and recovers "plain.txt".

VULN-1: Alice and Bob must be sure that nobody else has access to their private keys. They can lock them with a passphrase that needs to be entered for OpenSSL to access the keys, for example.
VULN-2: if Eve gains access to Alice's facebook page, or can induce Bob's computer to believe that some other computer is actually the Facebook web site, she can trick Bob into downloading Eve's public key believing it's Alice's. If Eve is capable of doing the same to Alice, she can pose with her as Bob. So Alice "talks" to Eve, using a format that Eve can decrypt, and Eve reencrypts it after tampering and sends it along to Bob, both ends being none the wiser. This would be a man-in-the-middle attack. That's why the authenticity of the public keys must be unquestionable.
Since neither Alice nor Bob have reason to use the keys they have published (they own the originals), once gained access to both Facebook pages Eve could replace both keys with others of her own making, and continuously monitor both pages in order to download any newly posted file and replace it with the appropriately decoded-tampered-and-reencrypted version. Since Alice and Bob aren't likely to verify their own files, and they haven't published the files' signatures (and even if they did, they might not notice they've been changed), they won't notice a thing. Not really likely to happen with something as public as a Facebook page, but in other scenarios the key distribution might be at risk. Of course, as soon as someone out of Eve's purview attempts to communicate with Alice or Bob and fails, the game's in the open.


Unsecured wifi but requires mac address... Secure? The organization I work for has site wide unsecured wifi, however to get access to it you have to supply your devices mac address to IT. Is this a secure method to prevent people from being able to packet sniff (or similar)? It is my understanding that it is not but IT are confident it is.

To give a bit of context to the sort of security needed, the organization I work for is large and very prominent. In addition the Wi-Fi is not just for work, as many employees live on site and use it, as well as there being multiple hotels on site that use it.

By unsecured WiFi, I'm guessing you mean 'open' and unencrypted. Packets on an open WiFi connection (one that is not protected by, say, WPA2) are susceptible to sniffing. All information is being transmitted in plaintext format. An exception is if you are visiting an HTTPS link and have end-to-end encryption on that website. All other HTTP traffic on an open WiFi is susceptible to sniffing.

Some organizations use MAC address to register a device before allowing it access to the Internet. In the event of a policy violation, they can look up the MAC address attached to the IP at the time and identify the machine -- and possibly the user. However, this is not an effective procedure since MAC addresses can be spoofed using tools like macchanger. Using such tools it is easy for even script kiddies to spoof a MAC address. Quite easy to do on a Linux machine. MAC addresses could be spoofed to any address such as 00:00:00:00:00:00 or a valid MAC address of another user.


How to perform RACH attacks on GSM mobile networks? I am studying various vulnerabilities on GSM networks and would like to know what hardware and software are needed to test such vulnerabilities.

A full-duplex software defined radio would be useful - it would allow you to send any GSM packet you want, even malformed ones which you won't be able to send with off-the-shelf GSM hardware.

On the software side you can always use custom code to generate your GSM frames, but you can have a look at OpenBTS and OsmocomBB for ready-to-use open source code that handles the GSM protocol. GNU Radio has a module for GSM as well. Wireshark can display captured GSM frames.


is it worth to implement a firewall on a web server you control? I see the main reasons for a firewall on a web server to be defense in depth and extra cushion for a possible admin error of running an unnecessary daemon. I'm trying to see if I am overlooking something. I am thinking that in a situation where you have a small infrastructure (a few servers) that you control it's not feasible to deploy a firewall.

As you've implied, security is about layers.  Systems get attacked and they get breached in a myriad of ways.  By layering our security solutions, we prevent our systems from being subject to a single point of security failure.  Sometimes people put firewall devices off-box and sometimes they also put them on-box.  Sometimes they do both for just the reason you state: to protect against configuration errors -- a very real, well-defined, and exploitable human condition.

However, from reading your question, it almost sounds like you do not have the infrastructure to support a firewall off-box.  So if it comes down to NOT having a firewall and having a firewall -- albeit on your web server -- then put the firewall on your server. The firewall prevents more than just connections to other services. It can prevent certain types of flooding attacks, it can prevent odd and malicious packets from entering the system, it can protect against operating system weaknesses, it can protect against mapping your network and it can protect against data being exfiltrated from your system.


Does SSL or HIP solve all TCP/IP security problem? I recently read this paper "A Look Back at Security Problems in the TCP/IP Protocol Suite" (https://www.cs.columbia.edu/~smb/papers/acsac-ipext.pdf) explaining few attacks at the TCP/IP stack.

One attack is at TCP layer (SYN flood, or DoS). Another is at the routing layer, i.e. RIP and BGP protocol. I understand that SSL and HIP provide encryption + authentication at level above IP layer, hence it doesn't really solve problem at the routing layer.

My question is that whether there are real/practical routing-based attacks when SSL or HIP are used, or are they merely academic problems? I mean, if the flow is encrypted and authenticated, what gain would the attacker have in being able to redirect or sniff the traffic?

What are the current techniques for securing routing protocols?

If "flow is encrypted and authenticated" the attacker is looking for a way to decrypt or break the authentication model.

Attacks that leverage MITM (man in the middle) methods use routing protocols (ARP and others) to put attackers 'between' the client and server where traffic can be captured and later unecrypted in some cases (Google WEP and Aircrack) or false authorization can be provided (Google SSLStrip where the client believes their connection is leveraging SSL/TLS, but in fact the connection is unencypted between the client and the attacker, then encrypted between the attacker and the 'secure' website.)

PS - Downgrade attacks can force web servers to use older and unreliable versions of SSL (like SSL3)... so unfortunately its not quite as easy as saying:

"what gain would the attacker have in being able to redirect or sniff the traffic?"


I don't use TLS extensions, I'm safe of HeartBleed? I know that the vulnerability exploits the Heartbeat response which is a TLS feature. Now, when testing some of my important sites, there was some wording that scared me, namely:

  TLS extension 15 (heartbeat) seems disabled, so your server is probably unaffected.

Does that means that there's another possible vulnerability related to Heartbeat, or the wording is like that just to leave the possibility of other vulnerabilities and don't make me feel safe?

These "heartbleed" testing services work by attempting to perform the OpenSSL TLS heartbeat exploit and seeing if it is successful.  There are three possible outcomes:

1) The server accepts the malformed "heartbeat" packet and drops it.  In this case, you can be reasonably certain the server is unaffected (or that a firewall or other service is protecting it).

2) The server accepts the packet and returns random memory contents in its response.  In this case, you know for certain that the server is vulnerable.

However, you're encountering another option:

3) The server states that it does not support the TLS heartbeat option.  It's reasonable to assume the server is safe, but you can't be certain.  It's possible, for example, that the server is using the vulnerable version of the OpenSSL library and can be tricked into accepting a TLS heartbeat packet.


Is it secure to overwrite unencrypted files with encrypted ones? If I have a text file on my desktop and I encrypt it (as in replace it with an encrypted version, not create a secondary file) will the old file still be recoverable? In other words if you replace the content of a text file is the old text still recoverable?

Deleted files are fairly easy to recover so that made me wonder if previous versions of a file is the same.

I infer two things from this question, so I will explain the first. You have a text file (we'll name it test.txt) My first interpretation:

Open text file
Select all content
Overwrite content with encrypted content
Save file

If you never copied unencrypted data, the data would be cached so it would be retrievable. If you're using Windows, depending on the version, you could do it with Volume Shadow Copy

Second interpretation. You have a file called test.txt and a file called encrypted-test.txt and you are copying/moving encrypted-test.txt to test.txt. In this instance the data is gone. In order to understand why, you will need to learn forensics, or read a briefer on it.

The tl;dr version: Deleted data isn't really deleted. Bits are re-assigned, and marked as available. While data is still visible on your disk, it is invisible to the naked eye. Until your disk reaches full circle to overwrite those segments, it can be retrieved. If data is OVERWRITTEN it is usually gone, but can be (possible) recovered. You may be able to retrieve fragments of the content of the overwritten file, but the entire data... It's gone.

  When a sector is overwritten it is exactly that.  The previous data is
  all overwritten and lost.  With earlier disk drives, maybe pre year
  2000, it was occasionally possible, with government budgets to recover
  data from some overwritten sectors and this has caused a lot of ‘folk
  law’ about such recovery.  With a modern, very high density drive
  drive this is now impossible, and any software package that say it is
  possible is ‘being creative’.  The only way to recover an overwritten
  file is by finding another copy - often called a backup. (source)

To answer your question: "Is it secure to overwrite files..." It is an uncommon way, but will work. If the goal is to make a file irretrievable, here is a horrible method to do so. Make an mp3, rename the mp3 to test.txt then overwrite it two or three times. Many forensics tools will attempt to fix the headers and trailers for file carving (identification). So mp3 headers become txt file headers. The entire document is now gibberish.


What security threats do tradesmen face in their use of IT? I'm designing a system for tradesmen and doing research into the security issues. I have the basics covered and am now looking for more specific threats.

What threats or vulnerabilities may be specific to tradesmen or may tradesmen be more at risk from?

[This is a very general answer, pending more detail in the question]

So you're asking for help doing a security risk assessment specific to the electrician profession. I'm no expert in electrical work, but here's some things off the top of my head to get you thinking in the right direction, not by any means exhaustive:

Physical security

Leaving their truck unattended in odd locations.
Entering unknown homes / buildings
Connecting their equiment to potentially malicious / malwary circiuts? (seems low risk, I'm scraping the bottom here...)

Information security

Make a list of sensitive information they handle and classify how sensitive it is, ex.:

Schedule of where they will be at a given time [medium]
Customer addresses [low]
Customer billing information, possibly including credit card numbers [high]
Alarm codes or key locations to enter a customer's home or building [High]
Diagrams or schematics of customer buildings [high]
etc

Make a list of ways this information is stored:

Paper
On phone (in sms)
On phone (in company app)
On Laptop (in Word documents)
On Laptop (in login-protected web site)
etc

Make a list of ways this information could be stolen, copied, or tampered with, and assess its risk:

Paper left in truck
Clipboard left on table while they poke their head into something
Phone stolen (phone encrypted and password protected?)
Laptop stolen (laptop encrypted and password protected?)
Connection between laptop and server intercepted (using https?)
Customer shoulder-surfs info they shouldn't see from phone / laptop screen (including passwords, which raises the risk of phone / laptop theft).
etc