Susceptibility of 7z encrypted archive files to man in the middle attacks

Context

What we have here is a symmetric encryption scheme implemented using 7z for encryption. Since I trust that, as you stated, the password is shared in a secure manner, we can consider it a pre-shared secret (at least pre-shared by the time of decryption). This means that the security of the scheme is dependent on the 7zip implementation of AES, etc.

Also, due to the nature of symmetric encryption with pre-shared secrets, an active attack (e.g. a man-in-the-middle attack) is no more useful than a passive eavesdropper.

  Does using a linux based operation to create such files offer more security than doing so with 7zip on Windows?

As long as your system is not compromised, either system would be equally fine. Which one is less likely to be compromised, etc, is a different question

  How susceptible would this kind of operation be to an attacker, government agency, etc... seeking to know what the contents of the archive are? Would that middle man need to intercept the entire file in order to potentially gain access to the contents?

As mentioned above, "intercepting" the file would be no better/worse than passively observing it, so a gov't agency would be no better off than your cloud provider, etc.

Whether they could (physically) compromise your devices, install keyloggers, use a $5 wrench to extract the password, etc, is a different question. How worrisome these threats are is up to you.

Cryptography-wise, the security is 100% dependent on the security of the encryption and the password. Since AES is pretty strong, I'd only worry about the password. (edit, thx @SteffenUllrich:) Since the password is being securely communicated, the only thing that you need to worry about is its strength. I recommend using a password manager to store and generate your password for the time between its creation and when it is sent to your friend/coworker/etc.

  What other flaws may have been overlooked in this approach?

(edited in later:) As mentioned in the comments, you might want to look into how 7zip hashes passwords, etc.

  Are there better alternatives that offer comparably equal ease of implementation?

Overall, I'd say that your current setup passes with flying colors. It's simple and uses established algorithms (i.e. AES).


How does SameSite cookie header prevent tracking?

The proposals in this document do not in themselves mitigate the
     privacy risks described in Section 7.1 of [RFC6265bis].  Entities who
     wish to use cookies to track user activity from cross-site contexts
     can continue to do so by setting cookies that declare themselves as
     "SameSite=None".

  Requiring that explicit declaration, however, gives user agents the
     ability to easily distinguish cookies used for stateful cross-site
     requests from those with narrower scope.  After the change proposed
     in Section 3.1, only those cookies that make an explicit
     "SameSite=None" declaration can be directly used for cross-site
     tracking.  It may make sense for user agents to use that information
     to give users different controls for these cookies, or to apply
     different policies for expiration and delivery.

  -- https://tools.ietf.org/html/draft-west-cookie-incrementalism-00

"This change will enable users to clear all such cookies while leaving single domain cookies unaffected, preserving user logins and settings. It will also enable browsers to provide clear information about which sites are setting these cookies, so users can make informed choices about how their data is used." -- Google Chrome.

This Google Chrome interpretation suggests we leave all the responsibility with users to perform these actions manually.  However, that is not the only possibility.  Other browsers could chose to automatically expire "SameSite=None" cookies after a certain length of time.  The exact behaviour could be configurable, or the browser could allow it to be customized by browser extensions.

However IMO they (Google, Inc. are prominent as the spec authors) have left a blind spot in this draft.  They claim to assume malice

  Blunt approaches to cookie blocking have been tried, and in response we have seen some user-tracking efforts move underground, employing harder-to-detect methods that subvert cookie controls [...] This is why Chrome plans to more aggressively restrict fingerprinting across the web.

On the other hand, this initial short draft doesn't discuss what happens if trackers correlate "SameSite=None" cookies with "SameSite=Strict" or "SameSite=Lax" cookies.

Changing to not deliver "SameSite=None" cookies when on the same site might resolve this.  However, I am not sure that helps when we still have "SameSite=Lax" to consider.  I expect this would also be a constraint on backwards compatibility, perhaps an impossibly restrictive one.

Also, the draft mentions "expiration".  Perhaps I am too ignorant or naive, but I would appreciate a reminder that trackers can renew cookies on every visit.  If we are really taking an adversarial approach, I would think we need to use a different mechanism.  I.e.  periodically purge tracking cookies, regardless of when the cookie was last re-set.


Does TLS protect against a man-in-the-middle masquerading as the client?

Does TLS actually protect against this somehow?

Why would it? All that you've done there (as the "attacker") is connect as a client yourself, with a completely incidental side of denial-of-service for another client. Unless you're using client certificates (mutual TLS), anybody can establish a connection to the server. You won't see any secrets from the client, because they aren't going to have a TLS connection to the server so they won't send any requests that might contain credentials, session tokens, or other sensitive data. You won't see any secrets from the server (aside from possibly your own) because you haven't authenticated yourself, so the server isn't going to tell you anything sensitive.

If you are using mutual TLS, well, you don't know the client's private key (for that matter, if you tamper in this way, you probably won't even learn their public key because the client won't go through with the handshake) so you cannot offer the signed token that is used to prove identity in mTLS. Without that, the server will either reject your handshake entirely, or ask you to authenticate in some other way, and again, you don't know the "legit" client's auth secrets (or any others).


You are in the same boat as many, many other technology companies. If the pentest company did not factor in all of your points above into some context for the risks they identified, you might want to consider changing companies.

Information disclosure presents a risk. You need to assess that risk and determine if the impacts are high enough to require that you mitigate that risk.

You may determine that the risks are simply not high enough to worry about it, in which case you accept this risk.

You may accept that there is a risk, and instead of plugging all the leaks, you use other, cheaper, methods to reduce the risk to an acceptable level. For example, if someone can know what OS and version you are running, then when a vulnerability is announced, you must be faster to patch or block access to that vulnerability than you might be otherwise. If you can do that, then that's a better way forward.

Another term that is gaining traction is "digital footprint". What info is out there about you? What do you disclose? Once you understand that, you then need to decide what to do if a malicious actor had all that info. What would you need to do differently? The big one is not to trust a someone just because they happen to know something internal to the company. Trust must be formalised and cannot be based on knowledge or familiarity. For instance, someone saying that they are from your bank should never be enough to trust them. There needs to be established ways to determine trust beforehand (approved phone numbers, 2FA, etc.)

So, how do you move forward as a company? The best case is to assume that everyone knows everything and mitigate what that means for you.


Unable to get EAPOL packets in monitor mode

I figured out the problem by rebooting my AP during Wireshark capture session. After doing that Wireshark could capture EAPOL packets, then decryption worked as well. However, I cannot capture all packets in the WLAN traffic and don't know why.


opening up Active directory to cloud services?

First off, and most importantly, they can NOT see passwords; however, they basically have read-only access to all of the contents of your Active Directory, such as: users, groups, group membership, computer objects, and group policy objects.  Additionally, the cloud solution could install a tool like Adsiedit on their workstation to view attributes in Active Directory that are not available via the standard Active Directory Users and Computers (ADUC) MMC snap-in, such as: last logon of user objects, last password change of user objects, etc.

One risk you are opening yourself up to is a low and slow brute force password attack against your users since the cloud solution will be able to obtain a complete list of usernames.

Since the function of the cloud solution is to have access to your users and groups, you are unfortunately not able to effectively restrict what they have access to.


Managing https security for IoT gateways

Many companies (like fortinet, stormshield, ...) use selfsigned certificates. They have a internal PKI which produce these certificates but they are not trusted by web browsers.
Many of them permit to upload the owner certificate. There is no big deal with this operation except that permissions must be carrefully configured

What do you need is probably a PKI to manage your own certificates. Then, you can set a secured https channel if you control the gateway and the client.
If you do not control the client, you cannot force it to trust your Certification Authority (CA), so you cannot ensure that https between the gateway and the client is safe (man is the middle is possible).
So you can propose to clients to add your CA as a trusted one or make your CA be signed by a certification well known authority (comodo, verisign, etc.)


Tor traffic correlation attacks by global adversaries

Tor doesn't necessarily protect you against a powerful attacker. Section 3.1 of the Tor design document states it:

  A global passive adversary is the most commonly assumed threat when analyzing theoretical anonymity designs. But like all practical low-latency systems, Tor does not protect against such a strong adversary. Instead, we assume an adversary who can observe some fraction of network traffic; who can generate, modify, delete, or delay traffic […]

However if you have a look at the recent leaks there was one about Tor: 'The king of high-secure, low-latency anonymity'. Especially the title of the presentation said it all:

So as far the leaks show it both NSA and GCHQ had a hard time to de-anonymize Tor users. What they basically do is to attack flaws in other systems like Firefox.

If you need a higher level of security you should take a look at special CDs. Tails is one of them. It routes all traffic throught Tor and tries to save you from some known attacks. Also the above mentioned slides write about Tails:

  Adds Severe CNE misery to equation

So it seems that Tails and others might bring you a higher level of anonymity and security against attacks. However if take targeted attacks into the equation you might want to read the documents from Der Spiegel and draw your own conclusions.


You should not use this in any production system, period. You're trying to design cryptographic primitives, which is something which is extremely easy to get horribly wrong. If you aren't yourself a cryptographer, don't try to design cryptographic algorithms - perfectly good ones already exist. (In general, you should use well-tested systems wherever you can in security - never roll your own primitive, avoid rolling your own protocol wherever you possibly can, avoid rolling your own implementation when practical).

In fact, this scheme is highly vulnerable to MitM attacks. A MitM is not someone who's listening in on traffic; they're active attackers, and can modify any communication going between the two parties. In this case, the MitM intercepts Alice's first message and encrypts it with their key; when Alice removes her encryption, the attacker now has it encrypted with their own key and nothing else. You have to somehow verify that it's Bob's key that was added in step 2, not an attacker's; your scheme doesn't even try to solve this.

A far, far better way to do this is public-key encryption. Alice and Bob give each other their public keys through some out-of-band communication, or a trusted third party verifies their public keys. Alice encrypts her message with Bob's public key, and Bob then decrypts it. You need to share public keys, but that's a plus: in your scheme (where you don't know the key Bob should use nor whether the message was in fact re-encrypted with it), you're extremely vulnerable to a MitM attack.

So use proper public-key encryption in a properly tested protocol, if possible in properly tested library code (note "tested" means "tested for security, which only trained experts can really do).


Android apps, does WebRTC IP-leak affect other apps than browsers (like youtube etc)

WebRTC only returns private IP Address of a cient and not public IP Address because WebRTC client has no idea what your public IP Address is if you are behind NAT and this is what WebRTC client wants to find out.

If you are using VPN, your request to STUN server - who is responsible for discovering your public IP Address and behind what type of NAT you are sitting at, sees your request coming from VPN.

But using VPN doesn't prevent webRTC client to send binding request to STUN server. Any embedded iframe can execute JavaScript that makes the browser initiate a transaction to a STUN server that can return the local IP address, along with the external IP and port number that can get through the firewall or NAT back to the browser.

Any app which is implemented with webRTC API is a webRTC client and yes they can leak your private IP Address. WebRTC is required by those apps who want to support P2P-VOIP and video calling so there are only handful of apps.

YouTube does not use webRTC. Facebook messenger and hangout use webRTC for voice calling so they can discover your private IP Address. Browsers were the first which came with integrated support for webRTC API and this is the list of websites that are using webrtc.

If you are wondering what What's app use for voice and video calls, it uses PJSIP libraries.

If you are using VPN and you find that your real IP Address is leaking, then that's the fault of your VPN client. It is not tunneling your traffic properly. STUN server should only see the IP Address of your VPN server. If this is not happening, it means that webRTC client is making STUN request outside of the VPN tunnel as shown in figure.


As with many/most/all things in security, this will depend on the threat model of the service(s) you're looking to protect.
The downside of IP address whitelisting as a single control is that it assumes that you can trust all the traffic that comes from the white listed addresses, which is often not a great assumption to make, especially on larger networks. On a smaller network where you control all the endpoints though, it might be a reasonable control to use.
Also, it's often not a bad control layer to use as part of an overall security plan. For example white-listing on the Internet, where you're only expecting traffic from a small number of source IP addresses, can cut a load of noise and random attacks off from targeting your service.
To provide one example of why you may not want to rely solely on white-listing. Imagine a scenario where you white-list a network for access to a service, and then within the white-listed network, someone starts a proxy server. Now untrusted users can use that proxy server to access your service.


Malware techiques via Linux Chrome and its effects, non-root

This question looks like it is actually multiple questions asked at once, and the questions are a bit vague. You might get better answers if you break your post up into a few separate more focused questions.

  Is it possible to visit a website with Chrome on
  Ubuntu and have that site execute code on my machine without
  explicitly downloading anything nor click on some Chrome execute
  question/popup? If so, can you explain using a specific example?

Here the question is vague. What do you mean by "execute code"? Of course, your browser will execute a bunch of code every time you access almost every website. Every website sends a bunch of JavaScript code to your browser and your browser executes that code using your CPU (via the JS virtual machine implemented by the browser).

Since this seems fairly obvious, it is not clear to me exactly what you are asking about.

  What I want protection from:

  Not able to retrieve my files under $HOME

In the absence of an exploit to break out of the sandbox you should be pretty well protected here. It would be a huge problem if the browser could read or write files in your home directory. If you find a way to do this probably you can make some money from a bug bounty. But I guess it would entail first finding a way to break out of the sandbox.

  Not able to identify key
  strokes / key logger

Key strokes entered into the browser, like in a form? Again this part of the question is a bit unclear. You would not normally be protected against javascript on the page reading keystrokes entered into a form on the browser page (even prior to form submission). Is this the kind of keystroke you are worried about, or do you mean keystrokes entered into a different application when the browser is running in the background? In this case, again, it would be a major problem if javascript could access those latter keystrokes, so again this would require to break out of the sandbox via some exploit.


In SSL/TLS the client suggests but the server chooses. The client sends a list of supported cipher suites, and the server selects one in that list. The list sent by the client is ordered by preference, but nothing forces the server to really honour the preferences of the client.

On both the client and server side, as @schroeder explains, the application software really does the job, but it may keep its configuration in a centralized emplacement, especially if the actual protocol implementation is provided by the OS. In general, such centralization is a lot more common in the Windows world than in the Linux ecosystem.

The FileZilla client uses GnuTLS for its SSL/TLS implementation; as far as I know, as a library, it does not use any centralized configuration for client-side protocol details, so whatever list of supported cipher suites sent by FileZilla will be decided upon by the FileZilla application code itself -- or, more probably, they just use the default settings of GnuTLS.


It looks like the have some basic input checking going on that is rejecting your response (although it is always possible that your @ is actually generating an error on their end for some strange reason).

Since it allows a request with an @, just not as the first character, I'd try a few things:

Try using a URL-encoded @ which is %40.  If their input checking logic has some flaws it make make it through and allow a valid payload.
Also, credentials can come with a username and password.  A colon is used to separate the password.  Therefore try this something like this: :user@newdomain.com.  If you're lucky that will result in https://www.example.com:user@newdomain.com which should accomplish what you want.
Like before, also try with an encoded colon, just in case: %3Auser%40newdomain.com

However, I'm just guessing at what their input validation rule is.  In cases like this it becomes a guess-and-check to try to figure out what they are checking for, and then some more guess-and-check to find a payload that circumvents their rules and also gives you something useful.

It's possible that the actual rule is that the URL must begin with a front-slash.  In that case you are probably left modifying the URL to only point to arbitrary URLs on the target domain, which is less fun.  I check this by attempting simple payloads like test (without any special characters or slashes).  If that also gives a 500 then they probably require starting with a front-slash, in which case I think you will be stuck.  It's also possible that they always concatenate your payload with a forward-slash, in which case (again), you are probably stuck.  That would be the case if you inject test and they return https://www.example.com/test.


I would contact the business in question.  They are the ones who are most directly affected and can also shut it down quickest.  Of course, the phishers will probably just move on to another server to host their requests, but if the site owners act quickly, it will at least immediately invalidate any past phishing messages that have gone out, potentially saving a lot of people a lot of trouble.

Contacting them through the website is not as bad of an idea as it seems.  Such hacks inevitably like to keep a low profile (which is to say that the website itself usually continues to work), because if they break anything the infection is more likely to be found and fixed, ending their phishing campaign.  Having previously helped people pick up the pieces after a wordpress site gets hacked, often times the "infection" can go on unnoticed for quite a while before someone finally notices.  Usually it is unintended side-effects that finally ring the alarm bells: I saw one site on a VPS where every email sent out by the spammers resulted in a small log file stored on the servers disk.  The logs weren't being monitored, but after a few million emails got sent out the server ran out of inodes and crashed.

All that to say that if you submit a contact through the contact form there is a very good chance that it will actually goes to the owners.  There are such a wide-variety of ways to manage contact forms on wordpress sites, there isn't an easy way for hackers to just turn it off or intercept it after breaking in.  I doubt they bother trying.  That being said, you can always try to find some public contact information for the company and contact them directly: you might not call them (unless you are in australia), but you can probably find an email.


Installing malware through websites is not as common as you seem to think. The malicious website needs to exploit a vulnerability in your browser which permits to get root access (quite uncommon).
So, as far as your browser is up to date, only the 0days (rare) could affect you.
But, even with less privilege, the malicious website could still tamper the behavior of your browser (spying you, insert scripts in the visited pages, ...).
Sandboxes can be a partial answer to this threat because they focus on isolating a process from the rest of the system (to avoid a malware spraying everywhere). They do are present in Android but they are not the ultimate protection.
Another way to protect you is to disable script (javascript mainly) in the setting of your browser.
But many websites will be broken as client side scripting is now a huge part of the Web 2.0.
Security experts, who want to keep their computer safe, rely on up to date Linux (android is Linux-based) and avoiding crap websites with malvertising (like porn, download, buzznews, ...).
It is less overkill than disabling the scripts.
Maybe take a look at the brave browser which is designed to limit the websites capabilities on your browser.


Those log entries look like normal scanning activity.

You can also notice that the scanner did not target your setup specifically, because multiple versions and directories are tried. And as you said, none of those actually exist in your setup.

  What I don't understand is, why does he use // rather than /

That's likely a bug in their scanning software (eg resulting from having a list of URLs, some of which have trailing slashes, and having a list of paths to scan, some of which have leading slashes).

They may not have noticed it, as it doesn't matter in many cases, as // is interpreted as / by many setups.

  What I am currently wondering is, what could potentially happen if a attacker has success with such an attack on phpMyAdmin? What could he do with it?

That really depends on the version. Here is an overview over some vulnerabilities in phpmyadmin. Note for example that the setup script was vulnerable to code execution in previous versions.

  I still had the setup folder still in the phpMyAdmin's root directory

Removing install folders is always a good idea, as the scripts are no longer needed and just provide an additional attack surface. Additionally, some developers don't bother coding them securely, as they could instead suggest that users delete them.

Still, phpmyadmin should be secure even if the script is not deleted (although looking at the list of fixed vulnerabilities, you can see that that was at least not always the case in the past). It's more important that you have a current version.

  Was my phpMyAdmin hacked?

We really can't tell you that with just the info you provided. The logs definitely do not tell us that, as they are just normal background noise.


How do I trust that I am typing my password for google

You do not.

Apps should allow you to do that through actual Safari browser in another window, where you can see the address bar.


Should I trust that the Android factory reset actually erases my data?

All android 7+ devices are enrolled with File Based Encryption (FBE) that encrypts /data partition from first boot. FBE keys are bound to TEE and user screen lock authentication. On factory reset, TEE clears stored keys and OS wipes the data. At this point, even if your screen lock password is known, it's not possible to decrypt recovered data.
It would not take longer than few seconds to wipe the data. Secure erase is not needed as clearing FBE keys is enough. Your device might be taking time in restoring factory image.

I use fingerprint unlocking, which means keys/password/secrets are stored somewhere.

Secrets that are bound to in-app biometric authentication are encrypted by the key that is generated & stored in TEE. Apps can also import cryptographic keys in TEE. Unless biometric authentication succeeds which is verified by TEE, TEE doesn't release keys of the querying app. This protection ensures that even if a malicious app compromises other apps, it won't be able to steal secrets of those apps without user authentication.
Apps that are storing secrets outside of TEE and not bound to user authentication are still protected by FBE. On app uninstall, associated keys of the app are deleted. On factory reset, TEE clears all keys.

reset - This permission allows to reset Keystore to factory default, deleting all keys that are not vital to the functioning of the Android Operating system.

Hardware-backed Keystore


Are TCP socket connections over private wifi encrypted using WPA2 PSK?

Since a private Wi-Fi is encrypted, does that protect the TCP server-client communication in any way?

Of course it protects the connection: to the level that WiFi connection is secure. And if the connection travels over anything that is not WiFi, then it is not protected. In itself, assuming that the connection is WiFi, or WiFi all the way seems just waiting for somebody to connect an additional wired router or switch, if you ask me.

Although it's getting better fast, previous WiFi protocols were all very vulnerable against attacks and the WiFi designers have been ignoring standard secure cryptographic techniques in the past. I would still not fully trust the security offered by it for any serious data. And that's assuming a professionally implemented WiFi connection, of course; all bets are off otherwise. Adding an additional layer seems very wise.

  How about connecting it over WAN ? In that case, cryptography would be mandatory, right?

WAN is just a designation of how far a network spreads. It does not carry any mandatory security. As such, it would depend on the specific WAN. My connection to the ISP does not offer enough protection for me to trust it. Hopefully some kind of VPN is applied, and then the security of that particular VPN needs to be investigated.

Just like WiFi, it may not provide full point-to-point security from client to server. And any changes in it may still break any assumptions made for your client / server security.

  I am thinking of using ECDH with AES 256-CBC as my encryption scheme.

Seriously, use TLS. Just using ECDH won't cut it and AES in CBC mode is vulnerable against padding oracle attacks. The chances of creating a secure transport mode yourself are so remote as to be near non-existent, so you have to use a common existing protocol.


How to proceed with IoT Vulnerability assessment?

TL;DR:

RFID Handling (your main input to the system)
Debugging interfaces (combine this with all the other steps)
Web app
Crypto stuff
Source code auditing
Side channel & fault injection (that's a kinda harder one)

1. RFID

I'd start with the RFID part (check out proxmark3). How does the arduino handle a 1KB ID? It should blow up. it might even throw up some of its memory somewhere.

2. Debugging interfaces

DEBUGGING INTERFACES. Can’t stress that enough. Check out One-Wire debugging protocol for example and my other interface it utilizes. Try to get a memory dump.

3. Web Application

Fire up wire shark or burpsuite and see what goes on. Mis-configuration is often not your biggest problem on custom web apps.

4. Crypto stuff

Keep in mind that the arduino is a low power device with horse power almost identical to carrying out calculations with pen & paper - these two with cryptography do NOT play well. Especially the RNG part. If it’s not hardware (like a white noise generator with reverse biased transistors for example) its most probably trash. Check out how every crypto that takes place is implemented, I'm sure you'll find something.

5. Source code auditing

This goes without saying, you'll have to check the source code. I leave it down there, because by the time you start checking the source code, you'll already have a very good idea on what's going on, when and why. I think that you'd already checked various bits on previous phases, but in this phase try to be much more thorough

6. Side channel & fault injection

Last but not least, I’d try faulty injection & side channel attacks. Voltage & clock glitching on such simple architectures, as well as power analysis is very easy (compared to an ARM A series processor for example).
ChipWhisperer will be of much use!
I think you even have two step pipeline so you can skip whole instructions :P

NOTE: Try to take a lot of notes during the assessment (how you did stuff, or how the system works) as well as pictures and screenshots on interesting/weird stuff. There's no such thing as "too many notes"!


HTTPS is not too heavy for an RPi at all - they're surprisingly powerful, and SSL is very lightweight in terms of CPU and memory usage. I've seen it implemented on 40MHz Atmega microcontrollers.

If you don't believe me, consider the fact that you can SSH into an RPi with no issues at all.


Using a 16-byte key just means they're using AES-128 rather than AES-256, which is still plenty secure. It doesn't matter much anyway since the key is being derived from a password; a 32 byte key is only more secure than a 16 byte key if it contains more entropy (which would be the case if it was a random key), but your password is unlikely to contain more than 16 bytes (128 bits) of entropy (I'd be surprised if it was even half of that). The way this will be broken is by brute-forcing your password through PBKDF2, not by brute-forcing the key directly.

What I find much more concerning is this:

  Users who forget their passphrase can still view secure notes or secure
  additional notes if they enabled Touch ID or Face ID on their devices.

While that's certainly user friendly, it sounds to me like they must be storing the derived key, which is generally a bad idea. This risk is probably mitigated by using a secure element, but it's still a risk to be aware of if you use Touch ID or Face ID.


Are URLs viewed during HTTPS transactions to one or more websites from a single IP distinguishable?

TLS reveals to an eavesdropper the following information:

the site that you are contacting
the (possibly approximate) length of the rest of the URL
the (possibly approximate) length of the HTML of the page you visited (assuming it is not cached)
the (possibly approximate) number of other resources (e.g., images, iframes, CSS stylesheets, etc.) on the page that you visited (assuming they are not cached)
the time at which each packet is sent and each connection is initiated.  (@nealmcb points out that the eavesdropper learns a lot about timing: the exact time each connection was initiated, the duration of the connection, the time each packet was sent and the time the response was sent, the time for the server to respond to each packet, etc.)

If you interact with a web site by clicking links in series, the eavesdropper can see each of these for each click on the web page.  This information can be combined to try to infer what pages you are visiting.

Therefore, in your example, TLS reveals only A.com vs B.com, because in your example, the rest of the URL is the same length in all cases.  However, your example was poorly chosen: it is not representative of typical practice on the web.  Usually, URL lengths on a particular site vary, and thus reveal information about the URL that you are accessing.  Moreover, page lengths and number of resources also vary, which reveals still more information.

There has been research suggesting that these leakages can reveal substantial information to eavesdroppers about what pages you are visiting.  Therefore, you should not assume that TLS conceals which pages you are visiting from an eavesdropper.  (I realize this is counterintuitive.)

Added: Here are citations to some research in the literature on traffic analysis of HTTPS:

Shuo Chen, Rui Wang, XiaoFeng Wang, Kehuan Zhang.  Side-Channel Leaks in Web Applications: a Reality Today, a Challenge Tomorrow, IEEE Security & Privacy 2010.  This paper is fairly mind-blowing; for instance, it shows how AJAX-based search suggestions can reveal what characters you are typing, even over SSL.  Here is a high-level overview of the paper.
Kehuan Zhang, Zhou Li, Rui Wang, XiaoFeng Wang, Shuo Chen.  Sidebuster: Automated Detection and Quantification of Side-Channel Leaks in Web Application Development.  CCS 2010.
Marc Liberatore, Brian Neil Levine.  Inferring the Source of Encrypted HTTPS Connections.  CCS 2006.
George Danezis. Traffic Analysis of the HTTP Protocol over TLS, unpublished.
George Dean Bissias, Marc Liberatore, Brian Neil Levine. Privacy vulnerabilities in encrypted HTTPS streams.  PET 2005.
Qixiang Sun, Daniel R. Simon, Yi-Min Wang, Wilf Russell, Venkata N. Padmanabhan, Lili Qiu.  Statistical identification of encrypted web browsing traffic.  IEEE Security & Privacy 2002.
Andrew Hintz.  Fingerprinting websites using traffic analysis.  PET2002.
Heyning Cheng, Ron Avnur.  Traffic analysis of SSL encrypted web browsing.  Class project, 1998.
Shailen Mistry, Bhaskaran Raman.  Quantifying Traffic Analysis of Encrypted Web-Browsing.  Class project, 1998.


What are the security implications of invalid free()?

It is suggesting the call to free() would cause memory corruption, the application would crash, and open the system to a buffer overflow attack.


Is it possible to read information entered into an iframe like this through a keylogger or invisible divs floating on top of the iframe?

Technically, the parent document can't capture a user's interactions with the iframe.1 But your main problem here is that the user has no way of verifying that the box they are interacting with is actually an iframe that is displaying your actual shop and not a copy on an entirely different domain. (A simple CSS overlay over the real shop iframe would work, too.)

On a potentially untrusted site, you simply can't establish a trusted iframe that users can safely interact with. Your browser's security indicators (displaying the full domain name and the green lock icon) only work for the top-level document. That's why authentication/payment providers use redirects to have users authenticate/checkout on a top-level document that they can trust instead of inside a  nested frame.

1That is, a keyboard event only goes either to the parent document or the iframe. But it can't be captured by the parent and still be fired inside the iframe.


Can Bluetooth earphone leak data between phones?

This answer assumes the earphones are a slave device and the phones are master devices. Each Bluetooth pairing is distinct using a different Longterm Key negotiated at the point of 1st pairing and then re-used as part of session authentication. There is no reason why a Bluetooth device should 'leak' information to another paired device.
Regards the 2nd part of your question, if your android is hacked, there is no immediate reason why an attacker could take advantage of a Bluetooth pairing to the ends you describe. Even if the attacker rooted your android they'd still have a job to use your iphone in this way. Apple phone security is pretty good. Everything is sandboxed. So they'd have to get you to grant permissions to the Bluetooth device they're masquerading as to use things like the camera and the microphone. It would be more straightforward to hack your iphone than to hack an Android to then hack an iPhone.


Is WPA2 WiFi protected against ARP poisoning and sniffing?

WPA2 is NOT protected against ARP poisoning.

When you perform ARP poisoning, you announce that your MAC address is responsible for a given IP address. All of this happens at a layer higher than WPA2 is aware of. Let's say layer 3. Because the WPA2 encryption link is down on layer 2, and packets destined for the attacked IP are now addressed to the attacker's MAC address on layer 2, they will be encrypted for the attacker.

Edit: Also, one should be aware of "Hole 196".


Will JavaScript be executed which is in an HREF?

I do not know of any browser that will execute Javascript for the particular example you mention.  I consider it highly unlikely that any browser will execute Javascript in this situation.  This is not related to newer protections in modern browsers.

However, I suspect you are still vulnerable.  If an attacker can insert markup into an href attribute, it probably means they can insert anything they want.  And if an attacker can insert anything they want, then bad things happen.  For instance, the attacker can make it look like this:

Click me

And that is bad news, because browsers will execute Javascript in that situation.  So this is a way that an attacker could try to exploit the XSS vulnerability.

Also, if there are no quotes around the value of the href parameter, there will be other ways to attack your system.  For example, Click me is bad news and will execute Javascript.  (Thanks to @AviD for pointing this out.)  Even if there are quotes around the value of the href parameter, if the attacker completely controls the value placed in there, the attacker may be able to supply his own quotes to break out of the attribute and then cause trouble, like this: Click me.  (Here the attacker inserted the value blah" onclick=alert(8007) ignoreme="blah.)  There are likely more examples like this.

The bottom line. I definitely recommend you fix the XSS vulnerability.  I suspect you are at risk.  Bad guys have developed a large number of surprising and clever ways of exploiting XSS vulnerabilities which you can't be expected to know about; as a result, if you have a XSS vulnerability, your best bet is to fix it preemptively and not take any chances.

Fixing the flaw.  To fix the flaw, I recommend that you use a combination of validation and output escaping.  First, ensure the URL's protocol handler is one of a whitelisted set (e.g., http, https, ftp, mailto).  Then, apply HTML escaping to escape all angle brackets, quotes, and ampersands before inserting the URL into the markup, and make sure the attribute value is surrounded by quotes.

The exact way of implementing this fix is language-dependent, but you can find a lot of information on the web about how to avoid XSS flaws in this situation.  For instance, after ensuring the dynamic value contains a safe protocol, in PHP you could use htmlspecialchars(., ENT_QUOTES) to escape angle brackets, quotes, and ampersands.  Or you could use OWASP ESAPI, which provides support for exactly this situation.

To learn more, I can recommend a good introduction for web developers.  This is just an introduction and you will need to read more, but it will help you be aware of the threats at a high level.  OWASP has some good resources on defending against XSS; for instance, they have a useful cheatsheet for how to use OWASP ESPI to avoid XSS vulnerabilities.


Does it make sense to use a third-party VPN when working from home?

However, I am less certain about the benefits of using a third-party
  VPN (NortonVPN in this case) when working from my home network. My
  employer is under the impression it is not safe to work from home
  without using NortonVPN.

  Are there valid technical reasons to require a third-party VPN when
  working remote?

If your employer requires\advises it's employees to use VPN in order to access to work environment, even if it's simply accessing an admin panel to a publicly published website, then they have a valid point.

All your data going to the endpoint, pass through network\application of your network provider, and anywhere in-between it can be intercepted. Even https traffic is not safe, since simply deploying a proxy which requires download and installation of it's SSL certificate is enough to decrypt and view all the data you are exchanging with the endpoint.

Using third-party VPN solutions however may not be the best solution. They can be susceptible to the data leak, and it might be too late to discover that. Besides, there are no guarantee that third-party VPN vendors are absolutely self-conscious about the data that passes through them. It would be best for employer to use there own, internally deployed VPN solution.

In short - Using VPN for work, even from home is a must. Using third-party VPN for these purposes cannot be sufficiently justified.


I'm not sure with regards to that specific method but you can use the aircrack-ng suite to launch a permanent deauth attack against an AP, effectively rendering it useless:

aireplay-ng -0 0 -a (bssid of target AP) (monitor interface)

This uses aireplay-ng to run a deauth attack -0 continuously 0, the -a specifies the target AP bssid and then you put the monitor interface on the end, usually mon0. The full command usually looks something like:

aireplay-ng -0 0 -a a4:2b:c2:23:a7:b2 mon0


How to detect malicious JavaScript in a PDF file?

I did some additional searching and found an interesting research-paper (easily readable and just 12 pages). The research is called Detecting Malicious JavaScript in PDF through Document Instrumentation.

In their research-paper they introduce a context-aware approach to
detect and conﬁne malicious JavaScript in PDF through static
document instrumentation and runtime behavior monitoring.

The following quotes and figure give insight in how their developed detection system approached malicious PDF detection.

Detection architecture

  Our system consists of two major components, front-end and back-end,
  working in two phases. In Phase-I, the front- end component statically
  parses the document, analyzes the structure, and ﬁnally instruments
  the PDF objects containing JavaScript. Then, in Phase-II when an
  instrumented document is opened, the back-end component detects
  suspicious behaviors of a PDF reader process in context of JavaScript
  execution and conﬁnes malicious attempts.

Phase-I Static Analysis and Instrumentation

  For suspicious PDF, the front-end
  ﬁrst parses the document structure and then decompresses the objects
  and streams. A set of static features are extracted in this process.
  When a document has been decompressed, the front-end will instrument
  it and add context monitoring code for JavaScript. In some cases, if
  the document is encrypted using an owner’s password, i.e., a mode of
  PDF in which the document is readable but non-modiﬁable, we need to
  remove the owner’s password. With the help of PDF password recovery
  tools like [28], this can be done easily and very fast.

Phase-II Static Runtime Detection

  The back-end component works in two steps, runtime monitoring and
  runtime detection. When an instrumented PDF is loaded, the context
  monitoring code inside will cooperate with our runtime monitor, which
  tries to collect evidence of potential infection attempts. When
  Javascript executes to the end or a critical operation occurs, the
  runtime detector will compute a malscore. If the malscore exceeds a
  predeﬁned threshold, the document will be classiﬁed as malicious.

The original URL to this research-paper (PDF) is https://cs.gmu.edu/~astavrou/research/Daiping_dsn14.pdf, also referenced from in the beginning of this answer. A mirror/copy of this document can be found here http://www.pdf-archive.com/2016/07/25/daiping-dsn14/daiping-dsn14.pdf.

Credits to: Daiping Liu and Haining Wang from College of William and Mary and Angelos Stavrou from George Mason University.


Based on the information so far it cannot be said if there is a problem or not. One need to watch out for several things:

If the administrative interface is accessible from the internet (usually not) and you have no password or a weak password then an attacker might get access this way. It is strongly recommended to have the administrative interface not exposed to the internet.
If you are logged into the router locally or have no or a weak password AND if the router is vulnerable to CSRF attacks or DNS rebinding (in case of no or weak passwords) then an attacker might get access by using your browser as a trampoline to access the internal interface of the router from outside.
Additionally there might be some kind of backdoor in the router where an attacker gets access. This might for example be a remote access for the ISP which due to bugs or misconfiguration is not restricted to the ISP only. But there were also real backdoors in the past left by the vendor.

If the attacker can get access to your router he can get usually get access to your internal network too. Typical attacks involve changing the DNS servers so that all of your traffic is passed through DNS servers controlled by the attacker. Or your router will be part of a botnet attacking other systems or sending spam. See for example A Massive Botnet Using Compromised Routers Is Ready To Attack,  Over 200,000 MikroTik Routers Compromised in Cryptojacking Campaign, VPNFilter botnet has hacked 500,000 routers. Reboot and patch now!, Over 65,000 Home Routers Are Proxying Bad Traffic for Botnets, APTs, How millions of DSL modems were hacked in Brazil, to pay for Rio prostitutes.

In other words: unless you can be sure that none of the attack vectors actually exist you should be worried. It is hard to be sure about this but choosing a router from a vendor with good reputation regarding security issues helps. For more information see routersecurity.org. Also check that the firmware of your router is up-to-date and that you are using a strong password. Also don't login to your router with your normal browser profile in order to prevent misuse of logged in sessions using CSRF - use a different browsing profile or incognito mode for this.


Many websites allow passwords equal to username or e-mail address. Is this not a security risk?

You are correct in that the NIST SP 800-63B does advise that verifiers check secrets "against a list that contains values known to be commonly-used, expected, or compromised:
....
Context-specific words, such as the name of the service, the username, and derivatives thereof."

From personal experience, I do remember interacting with services which have had this requirement: a Google search for a typical error message ("Passwords must not contain your username") does show that services out there are following NIST advice.

On the topic of implementing NIST, it also recommends against "repetitive or sequential characters (e.g. ‘aaaaaa’, ‘1234abcd’)". I don't see this implemented as often as other secret verification.

tl;dr: You're not wrong about the NIST specification.


Access to raw html source code after angular client side processing

You can use Chrome's Inspector to view the DOM tree as HTML. There you see the rendered result of the AngularJS processing.

But provided that you use AngularJS correctly, it takes care of all escaping and won't allow any XSS vulnerabilities (otherwise they are vulnerabilities in AngularJS itself).
You need to use $sce and ng-bind-html to make AngularJS insert random HTML unsanitized into the document.


With XSS (no matter if DOM based or reflected or stored, and no matter if done using eval or in other ways) attacker controlled Javascript is called inside the browser of the victim within the context of the victims current session.

This script can thus interact with the server through the browser the same way the user could interact with the server through the browser: fill in fields, press buttons, click links ... . While this directly only changes the state of the application on the client side it typically results also in requests from the browser to the server, which then change the application state server side.

While this kind of activity might be visible to the victim an attacker could also do it within some hidden iframe, in which case the state still gets changed (iframe shares the session) but is not that obvious to the victim.


To detect threats AV try to compare the file with known malware. But malware changes a lot and thus it is very common that no exact match to known malware can be found. In this case AV try to detect potential malware by comparing techniques and behavior used in the binary to known malware, i.e. use of specific packers or similar.

Of course such heuristics cannot be 100% accurate. This means it can happen that malware gets marked as clean (false negative) but also that harmless files gets marked as malware (false positive) because they've found to employ techniques seen in malware. Too much false negatives mean that malware gets not blocked by the AV but too much false positives means overblocking, i.e. that harmless files gets blocked as in your case.

Unfortunately a low false positive rate usually goes together with a high false negative rate and vice versa so AV vendors need to find a balance between these two which is acceptable by the users.The exact balance depends on the AV and the specific settings but typically we see a false negative rate of 2..6% (i.e. this malware gets not detected) with only few false positives (i.e. small but still existing overblocking). See av-comparitives for detailed statistics.

In your case a single AV vendor had some signature or heuristics which probably matched existing python based malware, just because you also use python. This is a typical case of a false positive and there is not much you can do about. Once your product is important enough AV vendors might explicitly white list it in order to avoid tagging it as malware by accident.


Providing 16 chars as first argument, you'll fill up the leaky buffer. As there is no space for a terminating null, the subsequent printf will echo your 16 characters and will continue to print whatever is on the stack until it encounters a terminating null character. This is your info leak. Addresses of ROP gadgets can then be calculated relative to your leaked address/es.


Each and every place where a user-input variable is inserted makes you subject to SQL injection. You should either use prepared statements, PDO, or escape the variables properly before appending to the original query.

As an example based on your code:

$v_email = "', NULL, NULL, NULL) --";

If I can append something like this to your query, and the SQL specific characters are not escaped, your webapp is vulnerable as I just changed the way you wanted the query to work.


Password hashing on a load balancing setup

This should be fine.

I'm going to split your question into two parts:

1. How does bcrypt work in terms of salt usage & storage?
Salts are used for a number of reasons - mainly to prevent rainbow table attacks and make unique hashes for non-unique passwords.

Rainbow tables are huge dictionaries of hashes and their plaintext. The idea is to look up the hash, and find the associated plaintext. In order to make this difficult, each password is salted with a unique value, ensuring that each password must be cracked separately.

If two users have the same password, with no salt, the hashes will be the same. This opens us up to coincidental attacks. If two users have the same password, but different salts, the hashes will be different.

The thing about salts is that you can store them in plaintext, because they don't need to be any more secret than your strong password hashes. As such, bcrypt simply stores the salt in plaintext within the hash:

$2a$05$TwentyTwoCharsForASalt$e2uDLvp1Ii2e./U9C8sBjqp8I90dH6hi

This is split out into the following tokens:

The 2a prefix to identify the hash as a blowfish crypt (i.e. bcrypt)
A two-digit work factor (usually limited at 04 to 31)
A 22-character salt value, from the values a-z A-Z 0-9 . /
The hash value.

As such, the parameters required for verifying the hash (including the salt) are stored within the hash string itself. When the verify function is called, it validates the prefix, extracts the work factor and salt, computes the hash of the given password (using the work factor and salt) and compares the result to the hash stored in the given hash string.

2. Can I do this in a load balancing scenario?
Yes. There are no issues here whatsoever. Just compute the hash on a machine, and insert it into the database. There is no point trying to distribute a single hash operation across multiple machines using cloud voodoo. Just tweak your work factor to fit with your performance and security requirements, and be done with it. If your server(s) can't take it, drop the work factor in your hash creation code. Since it's stored in the hash, new hashes will automatically use the lower value, and old hashes will be unaffected.

If you really really need to do it over multiple servers, set up a work distribution system so that each hash is computed on an available box. However, at that point I'd argue that you've got bigger problems than just hashing passwords.

Concurrency issues in your database system are unrelated to the hash function you're using, so if you're having problems with that I suggest you post a question on Database Administrators.


How does IPS terminate/decrypt encrypted traffic?

There are four ways an IPS can deal with encrypted traffic:

An IPS can act as a TLS interception proxy, where it becomes a man-in-the-middle for the TLS connection. This requires you add a root certificate created by the IPS software to your root trust store, or every encrypted website you try to visit will give a connection error. This allows an IPS to monitor the contents of encrypted traffic transparently, with some exceptions. This can be risky if the IPS software is insecure or untrusted, as you are delegating all trust to it.
An IPS can take the loss and analyze whatever it can without needing to decrypt the traffic (for example source and destination IP and port, traffic analysis-based heuristics, TCP header information, SNI, etc). This is of course less thorough inspection, but it does not rely on each client behind the IPS to install its custom TLS certificate, which can be a security risk.
If the software is integrated with the application using encrypted connections (which is possible if the IPS is running on the TLS endpoint itself, rather than on a separate hardware firewall), it can inspect the encrypted traffic after it has already been decrypted. This has the benefit of not requiring TLS interception while still being able to read encrypted traffic, but has the downside of only working with supported applications, and needing to run on the endpoint.
Any encrypted traffic can simply be blocked. This allows the IPS to read most traffic and deny that which it can't read, but at the expense of usability. However, an unauthorized entity can still communicate by using a non-standard or obfuscated encrypted protocol that the software is unable to understand. Using protocol whitelisting is not a solution either, since it would be possible to send encrypted data in the contents of an HTML page over plain HTTP.

As for terminating an encrypted session, that is easy. TLS is on a different layer than TCP (in the OSI model, TLS is layer 6, whereas TCP is layer 4). That is, TLS is encapsulated within the TCP connection and does not encrypt TCP-related information at all. In order to tear down a connection, all the IPS has to do is send out an RST. Once the TCP connection is dead, so is the TLS session.


Stacking Encryptions (Stream over Block)

Encryption using rather different algorithms is probably not less secure than encryption with just one algorithm. There's a meet in the middle attack possible which may influence the security to be about the strength of AES + a single iteration of RABBIT though.

AES-256 is (thought to be) so secure that it will likely not be cracked even if quantum computers become a possibility. So basically you are only protecting yourself against significant breaks of AES. In that sense this kind of scheme only protects the part of the protocol that is most likely to be secure in the first place.

Cryptographic errors are easy to make. In that sense the more complicated the protocol the more likely it is that it is in error somewhere. If there is an error then the security of the layered encryption can easily be negated.


Are there attacks to steal database records from memory in cloud?

Stealing data living on one VM directly from another VM is not a realistic attack scenario currently. While there are side channels which allow a small information leakage it is currently more a theoretical and expensive thing to exfiltrate data that way.

Much more likely are attacks directly against the VM containing the data (i.e. SQL injection, SSH brute force....). There is nothing special VM or cloud related with these attacks, i.e. once you have system privileges or even kernel privileges you can access the memory of any process.

Less likely but still realistic are attacks against the hypervisor, like breaking out of a neighbor VM or attacking the system where the hypervisor runs on. Once you got system or kernel privileges on the hypervisor this way you get full access to all VM's in control of the hypervisor. This includes full access to the memory of these VM.


how to know which encryption is been used

The general answer is: do some reverse-engineering on the application. This notion of "reverse-engineering" is rather large; it includes:

Reading the documentation (if any) or other design notes accompanying the application.
Talking with the developers who built that application (it is amazing what people will say after two or three pints).
Going through the source code, if available. From an attacker's point of view, source code can often be obtained by going through the dumpsters outside of the developer's offices, to look for discarded hard disks or backup tapes.
Making test cases yourself: register on the application with a password that you know, and see what it becomes in the database. In particular, test whether changing your password several times and getting back to the first one brings you back to the same stored value, or another one. Also, test if two distinct users with the same password have the same stored value.
Disassembling the application binaries. This is especially simple with Java bytecode and .NET assemblies (for the latter, I have used ILSpy with success).

Without such reverse-engineering, you are back to guessing, a method whose efficiency is questionable. In your case, the sample you show looks like the Base64 encoding of a binary value of length 8 bytes (6b 33 b0 28 fa 14 60 fe, specifically). This suggests an algorithm that produces 64 bits, maybe a variant of the traditional DES-based hashing but without the salt.

Be mindful that a password can be encrypted, but, much more often, it is hashed; sometimes, it is MACed. These are very distinct notions and you will find a lot of documentation that is very confusing and confused on this subject. So, as a reading guide:

Encryption: using a key, transform some input data into another format that is unreadable to anybody except those who know the key; with the key, the transformation can be reversed (this is called "decryption"), yielding back the original value.
Hashing: mash and mix the input data into a fixed-length output. There is no key; the function is deterministic and public, and everybody can apply it. Hashing is not reversible; if the hash function is good, then the only method to find the original input (or at least a matching input) is luck (you try inputs until you find the right one).
MAC: somewhat equivalent to a "hashing with key". You need the key to compute it; but even with the key, it is not reversible. A MAC is to be verified, not "decrypted".


Why does an external pentester testing my Azure website ask for IP, Gateway, DNS and VPN credentials?

If the server is publicly accessible then you don't need to worry about VPN connection info. Security assessments are often performed on sites before they are exposed to the internet and the site is only accessible on a private network so they will ask for you to provide these details if that is the case.

The DNS name that the application will have will also be useful to the consultants who are testing the application. For example if they have a site at www.example.com and you are developing a replacement that is currently hosted at beta.anotherexample.com or just has an IP address, they may need to configure their hosts file for the site to work properly - this is quite common if you have developed a site in a CMS like wordpress and it expects all links to start with www.example.com even though the DNS name does not point to your server yet / the website hasnt been deployed to production

Probably the best thing to do is to ask for the mobile phone number of the tester that will test your site and chat with them about what they need. It will be useful to have this number (and for the tester to have your's) in-case the tester accidentally takes your site down or you need them to pause testing for some reason. They may also be friendly and be allowed to give you an informal 'heads up' of what the report is about to contain :)


Which practices should i use while generating SMS codes for auth on my project?

I'm using good algo? Maybe i need to use something better?

Which generator is being used by Math.random()?
Have a look at the footnote on that Mozilla page:

Math.random() does not provide cryptographically secure random numbers. Do not use them for anything related to security

Will it increase security if i will check previous sent code for {$n} last minutes from db and regenerate another one if it will be same (brute same code twice case), so user always gets random 5941-2862-1873-3855-2987 without 1023-1023-2525-2525-3733-3733 case? I understand that chance is low, but anyway...

No. You shouldn't try to make numbers "more random" by avoiding repetitions. It's the property of random numbers that there is a chance that the next one will be the same as the previous, and it's ok. You would actually weak it by discarding those $n last codes.
I would actually try to implement HOTP / TOTP on the sms codes. You don't really need to, a random number would do, but that way you could easily change the users from sms authentication to local-app authentication, with no changes on the verifier code.


WifiKill uses a simple ARP spoofing, i.e. it floods all the devices on the WLAN and attempts to impersonate the access point.

There is nothing you can do on your device as is (rooting changes matters: see below) - you would need to deploy an IP filter on the same, and drop all ARP packets. This would prevent you from talking to any device in the WLAN. To be able to do that again you would need to manually prime your device's ARP cache with values you know to be correct (a.k.a. static ARP entries).

Social engineering

You could ask your roommate to quit being a jerk, and/or establish some acceptable usage policy and/or timetable. Why does he need to use WiFiKill? Does he need to?

But supposing you don't want, or can't, get him face to face... and assuming you do have the right to the connection, i.e., it is (in part at least) your access point and Internet connection, not his... there are ways.

You can start making life difficult for him, and have him perceive it is caused by his behaviour, without ever saying so. For example: you can start complaining about your unstable access point and begin resetting it to factory defaults every now and then. Change your WPA key and give it to him again, saying you had to reset the blasted thing yet again ("it keeps disconnecting"). He (and you too) will then have to reinsert the key. After some time, he will come to understand that every time he uses WFK, he gains a few minutes' full bandwidth... and then no bandwidth, and a whole evening of listening to you whining and ranting about unreliable hardware.

You might start spawning conspiracy theories by asking him whether it is likely that there's an incompatibility between your (not his!) phone and the AP, or start noticing unlikely coincidences ("Every time the microwave starts, the connection drops"). After a while grasping at straws, you can latch on the real coincidence ("The network disconnects me only when you are home") and suggest he takes his phone to the shop for a repair. This will reassure him that you accuse him of no wilful wrongdoing -- but at the same time it will be clear that you're onto something. This could be a minimally confrontational way of clearing the air. You can tune the "coincidence" you notice, in order to try and work out a compromise ("Probably when you play online games on your phone a weird combination of bandwidth, access point chip brand and magnetosphere resonance disconnects my phone. Not anyone's fault, but still -- can you tell me when you're going to have a long gaming session?").

The same approach can be used to drive home economic threats ("We need a new wireless access point with a stronger antenna. I found one for $180 -- if this AP reset I'm going to try does not work, we'll need to think about purchasing a new AP. How much could you contribute?").

Android apps protecting from WiFiKill (root may be required)

I am far from sure since I haven't tested it personally, but this seems what applications like ARP Guard, ARPProtect or WiFi Protector do. The latter explicitly mentions WiFiKill. Downside: to fully protect a device you need to tamper with its network stack at a low level, so defense needs root too.

iOS

I have no experience on iOS (editing is welcome!), but there are hints that iOS7 employs some ARP spoofing mitigation techniques - possibly slow-caching, glean-refusal, gratuitous-refusal or others. Owners of iOS7 devices might have nothing to worry about.

Built-in access point protection (and its drawbacks)

There is also another way, but it depends on the access point.

Some access points have a special mode of operation - sometimes called "Private Mode", "Client Isolation", "Guest Mode" or "Privacy" - whereby, however large the pool of devices connected to the AP, you only see yours. You cannot "talk" to the other devices. The AP will accept packets from you to it, and not forward any other except for NATting you on the Internet.

This allows e.g. users in a café to be relatively safe against their neighbours' curiosity - you might have a totally open system with services exposed on your laptop, but when you're connected to a private-mode AP nobody else can see them.

I believe that an ARP spoof in such a setup would silently fail. The down side is, not all access points support this.

VERY IMPORTANT: if you have any WiFi device you need to access, e.g. a WiFi printer, it will not work in Privacy Mode, and it might still not work if connected via ethernet cable to one of the Ethernet ports some "APs" have. If this is the case, you might have to query the shop for the exact APs features, or give up on this possibility.

UPDATE: some even fancier Netgear AP have the option of excluding a sub-pool of IPs from privacy mode. So you can have the AP as 192.168.1.1, the WiFi printer and DLNA servers as .2 and .3, use DHCP to assign addresses from .8 to .254 to newcomers. Your being assigned 192.168.1.34 will tell you that there might be (or have been) other (33-8) = 25 devices connected, but you will only ever "see" and be able to harass .1, .2 and .3.

ARP filter on AP

Several access points have the feature of filtering ARP in various ways. This can occasionally break other technologies, notably iOS AirPrint, that rely on ARP "openness", but it may be worth pursuing. On some systems this goes under "bandwidth protection".

Most APs based on Atheros AR5002G should either have the feature available, or it can be activated with the appropriate hack (see below).

Adding protection to the AP if not built-in (not for the faint-hearted)

If you're feeling adventurous and your AP supports it, you could try and flash it with a version of DD-WRT supporting client isolation or some flavour of ARP filtering.

Or you can say that you've had it with your faulty APs that always disconnects, and you buy a new AP which already has, and accidentally comes already configured with, Privacy Mode and/or ARP filtering.

A different approach, again AP-based

Another possibility, also available on some APs but not all, is the "split SSID"  or "Twin SSID" mode. In this mode the AP publishes two SSIDs, with different keys. In some APs you can also set the bandwidth limitation for one or both networks. You can then get even with your "friend" by copying the current SSID and key to the guest or low-bandwidth connection, then giving the other SSID the name of your neighbours' daughter or pet. Of course, if he gets suspicious, a little investigation will reveal the truth.

In general

Several techniques are available to protect against ARP spoofing. There are some silver bullets, but they're not ubiquitous. The historical (and arguably outdated) tendence was to glob any ARP information you came about, and use it to improve network performance. This is an effective strategy, as long as you can trust that ARP information. Otherwise you need to only consider information you requested, and possibly refuse it if it looks suspicious, if the context seems fishy, or if some extra checks fail to deliver. To do so, of course, introduces a delay.


Long answer, see TL;DR below!

I don't think it's an Nmap problem, but rather a port-forwarding problem. I imagine you are scanning from the local network (if that's not the case, please ignore this).

Port forwarding often don't work from the local network, for a very simple reason. Suppose this is your network:

(A)--+
     |                    (           )
     |---(Rpr--R--Rpu)---(  Internet   )---(X)
     |                    (           )
(B)--+

A and B are two computers in your local network, both with private IP addresses, R is your router (which does the NAT and port forwarding), with one public address (Rpu) and one private (Rpr) on your LAN. X is a computer on the Internet, with a public address.

You have configured port forwarding on R so that packets arriving on Rpu:4245 (this means IP address Rpu, port 4245) are forwarded to A:4245.

When X sends a packet to Rpu:4245, it arrives to R, which translates the destination address to A:4245 and routes the packet to A. When A answers, it sends a packet from A:4245 to X. This packet is sent to R as its destination is outside the LAN and R is the gateway. R changes the source from A:4245 to Rpu:4245, and route the packet, which arrives to X as a packet from Rpu:4245 to X, everything is OK.

Now when B sends a packet to Rpu:4245, it sends it to R (because Rpu is outside the LAN and R is the router). Suppose R does the port-forwarding anyway, it sets the destination to A:4245 and routes the packet (from B to A:4245) to A. When A answers, it sends a packet from A:4245 to B. And this time it won't send the packet to R but directly to B, since B is on the LAN. The packet arrives to B as a packet from A:4245 to B, and hence cannot be seen as the answer to the packet from B to Rpu:4245, the source address does not match.

This could work if R also changed the source address to Rpr (or Rpu, or any address outside the LAN), because in that case, A would send the answers to R and R could reverse-translate the addresses, but that's probably not the case.

TL;DR. Run your tests from a computer outside your LAN with: nmap -sP4245 -p 4245 x.x.x.x (-sP4245 instructs Nmap to use a SYN packet to port 4245 during the ping scan). From your LAN, you can only check that the port is open by scanning (with the same options) your private address, but that leaves the port forwarding setting untested.


What preparation do I need to fullfil for OSCP?

Edit: I'm an OSCP now, and you can read my review here, but to briefly answer your question.

OSCP is nothing like C|EH, SSCP or any of the other courses I know that are out there. It is extremely practical and leaves tons of opportunities for further research and development on your own.

If you're looking to learn something new or establish ground in I.T. Security, the PWB course is awesome. It teaches you the ropes, but leaves you to climb them ;D.

Generally a 60 day course period is recommended if you can dedicate 3-4 hours daily, or 30 days if you have prior knowledge or can go 8 hours a day consistently.

Rather than another accolade the course is meant you teach you know to deliver offensive security at a practical level, not only in theory. You take this course and there will be countless times you will be frustrated, bogged down, discouraged, but you have to keep going and as they say "try harder".
The labs are not difficult, they're challenging. But the high you get when you break through the obstacles is worth it and the cost.

If you're doing it as a cert. then it'll be disappointing, if you're doing it to learn, welcome to the lot.

The course doesn't have any major prerequisites as they teach the basics from ground up. This is what I feel you'll need:

Knowledge about TCP/IP
Linux Usage & Navigation
Basic understanding of exploits and payloads in Info. Sec.
Basic Scripting/Programming Knowledge Helps
...and the most important, determination.

Good luck.

Further Research References:

http://proactivedefender.blogspot.in/2012/01/oscp-my-review.html
http://www.ethicalhacker.net/component/option,com_smf/Itemid,54/board,58.0/


If I have my neighbors wireless router password, can I access his data with a smartphone?

Probably harder to do with your phone than with a laptop, but attacks can be (and have been) mounted with a phone. Your neighbor should definitely change his password just to be safe, but IMO his chances of being attacked aren't as high as one might expect.

The attacker would have to find the location of the network if he didn't know it already, and then he'd have to get physically close enough to get onto it before the password would be of any use to him. Heading over to the nearest fast-food joint and sniffing on the free Wi-Fi there is much easier. Even cracking Wi-Fi passwords (particularly WEP, although that's not in widespread use anymore) is probably easier than actually moving around (at least for me). With cracking, you have the added bonus that anyone whose network is easily crackable is probably pretty lax about security, so additional opportunities are likely to present themselves.

To learn more about this, I highly recommend using google. There's a lot of information on the internet, or so I'm told.


Is there a way to steal PHP or ASP code from a web server through the HTTP(S) protocols?

You are correct that this is not possible without mis-configuration or security vulnerabilities that allow it.

Generally, the most likely culprits when it comes to coughing up application code are commented out code, backup files that have extensions allowing them to be delivered directly to clients without processing, and probably more likely that all other culprits combined, are overly verbose error messages.

So, it's not just a matter of making sure that your application behaves correctly when you use it correctly, but also that it behaves correctly when abused.

That said, code theft is, generally speaking, a highly overrated risk.  Your code isn't that special.  I say that merely because in my experience, there's very little code that is.  It's highly unlikely that anyone really wants to steal it.   It's far more likely that the sort of flaws I enumerated above would be used in order to obtain sensitive information such as database credentials, or to expose the existence of weaknesses in application logic that could lead to exploitation by common vectors such as SQL injection.


Web server attack methodology: why bother with manual tests if vulnerability scanner does it all?

You have several assumptions here:

scanners can find all vulnerabilities
if a scanner cannot find a vulnerability then there are no vulnerabilities
all manual tasks can be automated
attackers would only use automated tools and not manual approaches
manual approaches cannot be turned into bespoke automated tools
finding vulnerabilities is the same as exploiting the vulnerabilities

None of these assumptions are universally true.

Automated scanners help make the process of finding vulnerabilities more efficient, but they are far from perfect and far from complete. Scanners are also not designed to exploit the vulnerabilities in a useful way.

In practice, you want to manually test the results of a scanner (false positives) and perform manual tests to look for things that the automated tool might have missed.

Attackers will use a mix of approaches and then often create or modify a tool to exploit the vulnerability so that it is repeatable and reliable. But that doesn't mean that the tool will work in other situations.

Automated tests are the basic threshold. If your site/program fails an automated test, then you've made a pretty bone-headed error and it should be fixed immediately (because it will be easy to find). But I've seen some cases where a developer has added a check for 1=1 in their SQL in order to hide from automatic scanners, but I was able to exploit the site using 2=2 (modern SQL scanners account for this now). I only knew that from manual testing and personal experience. You can't encode experience and intuition in a tool.

Coding is an insanely complex activity. That means that the errors can be complex, too. No tool could be created to look for or to exploit all vulnerabilities.


How is a Tor hidden service immune to exit node attacks?

The node right next to the hidden service in that circuit does know its IP, but it knows nothing about it other than that; not even that it's a hidden service, nor the message that is being sent to it -- it looks just like another node in the circuit.


Wordlist generator with a certain pattern

You could use a tool like Generex to generate strings out of a regular expression. I think your case would be:
[Aa]meri\d{3}\s?[Cc]a\s{0,4}#

I limited the latter space to max 4 so the regex would be able to terminate. There are some online tools available that do this too.


How to implement secure user sessions using HttpOnly cookies?

No, your approach is definitely not secure.

HttpOnly is intended to prevent malicious Javascript from accessing the cookie. A malicious user with access to the browser (including the user himself) can do whatever they want to the cookies, or even ignore them and make up their own cookies to submit with the request.

If you would like to keep something somewhat close to your existing design, I would suggest encrypting or signing the contents of the cookie in order to make it tamper-resistant. Another option is to simply store a session identifier in the cookie (with sufficient entropy) and store the user ID in session state on the server side.


How mobile app WiFiKill can cut off internet access to neighbor devices?

WifiKill uses ARP poisoning:

  The app works only with rooted phones and works, similarly to FaceNiff, by spoofing ARP replies to trick other devices on the network into thinking your Android phone is the router. WiFiKill then drops all their network packets. To the victims, it still appears as if they are connected to the network, but the internet just appears to have stalled.

source

A similar program is Ettercap.


Do malicious downloads bypass integrated browser downloader, if so how does that happen?

The important thing to understand here is that "browsing" as such is dangerous if your browser is vulnerable and you visit the wrong site. The problem has nothing (or little) to do with what most users call "downloading", i.e. the intentional download of a file in order to save it on disk for later use (like downloading a pdf, an exe, a picture or movie or whatever).

In order to understand what happens you need to think of what computer programs are. They are processes which run in memory. They accept input and produce output. I'm of course simplifying but you'll soon get the idea. Input is what you provide (mouse clicks, URL information, form data you fill in etc.). Output is mostly what is rendered in the browser window and what you consume through your eye and your brain.

Another input to the browser program is what the browser downloads from the site(s) you visited. Keep in mind that it can be hard to keep track of what is actually loaded from the site. The site might link hundreds of other sites in order to get pictures, styles, javascript, create ads, include facebook likes etc. etc.

Now how are computer programs compromised? Through malformed input in situations where programmers forgot to check input for correct format or made programming mistakes otherwise. In our case: If you visit the wrong site then it will send malformed html, css, malformed movie format, .... (whatever the hacker finds that can be exploited) to your browser hoping that you're using a vulnerable version. Then, in the browser process, a buffer overflow or similar happens and the hacker achieves RCE (remote code execution, which means he turns your browser into a tool of his will).

So in case the browser is vulnerable you don't need an intentional download in order to get hacked. If it's done well, you won't even notice when it happens.

Browser extensions usually make this worse. Generally, the more software you run and that processes external (unverified) input the bigger the attack surface becomes.

So what can you do?

Make sure your browser is patched up to date
Avoid stuff which is known to be vulnerable (flash player)
Avoid sites which look fishy
if you can, use virtualization technologies (use a browser in a virtual machine. Reset the VM image after each use)


Try injecting the xss payload directly into the request header.


32bits Linux - Simple stack overflow - EIP never overwritten

This difference might be there due to different stack alignment used on the server side. For setting up the stack alignment, "mpreferred-stack-boundary" option is used.
More:
https://stackoverflow.com/questions/10251203/gcc-mpreferred-stack-boundary-option

Hope this helps!


An OCSP responder is not part of a SSL server; it is maintained by the Certification Authority which issued the certificate for the SSL server. Indeed, the OCSP responder publishes information on the revocation status for certificates, and it is the CA who chooses which certificate is revoked and which is not.

Thus, OCSP responders usually come with the software for managing the CA. See for instance EJBCA, an Open Source PKI, which comes with its own OCSP responder. There are also stand-alone responders, which feed on CRL produced by the CA; see for instance this one.

Either way, an OCSP responder is only good as far as validators talk to it. Software trying to validate a certificate, in particular a Web browser which acts as client to your server, will use a given OCSP responder only if they know that it exists and where to find it. In practice, this means that the URL to the OCSP responder has to be included in the certificate itself, as part of an Authority Information Access extension. Of course, it is up to the CA to include, or not, such an extension in the certificate, when it issues it.


TLS encrypted passwords on my Android - safe?

No, don't worry. The latest version of TLS is not cracked and your passwords sent using it will be safe.

But the TLS is not related to Full Disk Encryption (FDE), FDE is only applicable to data at rest (when your phone is off), whereas TLS is used to handle data during communication. So if you have stored your passwords in your phone in some text file or database etc., then TLS won't help you. But if you enter your passwords in IM from your brain, then you are protected by TLS and will be ok :)


How can vulnerability researchers find flaws in OSes / Embedded Systems?

Your question has many false assumptions, and these are the reason for your confusion.

  An OS doesn't come with source code or binaries.

Yes, it does. Open-Source Operating Systems like Linux come with source code, which is regularly looked at for possible vulnerabilities.

Closed-Source Operating Systems like Windows still come in binary form. If you install your operating system on a hard drive, this hard drive then contains all the code necessary to run the operating system. Furthermore, these binaries come in a specific architecture for the CPUs they are designed to run on. As such, anyone can look at the instructions that the Windows Kernel executes, as long as they have a copy of the operating system.

  Embedded Systems don't come with source code or binaries.

Embedded systems are a bit different than "regular" computers, and require specialized hardware to analyze. For example, to analyze a "custom" chip, researchers could dissolve the chip bit-by-bit and thus reverse engineer how the chip works.

  How can a researcher understand the underlying system?

Reverse engineering is a simple process: You observe the system, using knowledge you acquired analyzing similar systems, and see if you can draw conclusions from that. For example, when looking at communication between two chips, I can see that communication between two chips is always calling first, and the other chip always answer. The "caller" always sends data in a fixed width, while the "responder" sometimes sends data that's 8 bit long, sometimes 16, 32 or 64 bit long. Sometimes the answers are much longer.

Can you guess what the responder is? It's most likely some sort of storage.

As more and more of the communication is being observed, the "protocol" that is used to communicate can be deciphered. It doesn't need to be complete, but it could be observed that the communication is always in this form:

+---------+---------+---------+---------+----------------+------------+
| 2 Bytes | 4 Bytes | 2 Bytes | 8 Bytes | Variable Bytes | 0x00FF00FF |
+---------+---------+---------+---------+----------------+------------+
| Unknown | Unknown | Unknown | Length  | Payload        | EoT        |
+---------+---------+---------+---------+----------------+------------+

While you might not know yet what exactly these bytes mean, you can look at correlations between them. For example, you notice that the 8 bytes denote the length of the payload, followed by the payload, followed by the constant 0x00FF00FF.

This process keeps going, until you can be reasonably sure that the "calls" and "responses" you see all make sense. You can then attempt to insert your own "calls" and see if the responses are what you expect them to be.

  Obviously, black box research will not produce good enough results.

The universe didn't come with a conveniently formatted man page, but we observed how things acted, drew hypotheses from that, made experiments and confirmed those hypotheses.

This allowed us to understand classical mechanics, thermodynamics, fluid mechanics, acoustics, optics and more. None of these things came with documentation, and they were essentially the same as a black box to us.

Reverse Engineering is the same thing. You observe, you hypothesize, you experiment, you succeed.


Beyond patching, how can I reduce the risk of browser exploits?

Given that a lot of browser base malware is delivered via ad networks, a decent way to reduce risks would be to use an ad blocker (e.g. Ad Block Plus).

Also something like Ghostery can disable a lot of, likely superfluous, 3rd party content on sites you're browsing, which again could host malware.  Realistically any content you don't visit is content that can't give return malicious content.

Additionally things like reputation filters can be useful, either those built into the browser, or one's from 3rd party security software providers.


Explain SSL advantages for e-commerce to layperson?

There are a couple of angles:

I they have no technical interest at all, the first aspect is that, as far as I know, the credit card industry requires the encryption of the transmission (and various other things). From a regulatory point of view, this should be enough to push to use HTTPS.
For those two want to know a bit more, first explain that plain HTTP traffic happens in clear.

Then, if you want to run a demo, you can simulate a MITM attack, but you can also demonstrate passive eavesdropping more easily: plug a machine running Wireshark on the same router1 as their machine and show them what they're browsing. Of course, only do this if you have obtained the permission from whoever is connected to that network; make sure what you do is legal first in your jurisdiction. Then, explain that anyone with access to the network between their machine and the server could do this. To the non-technical user, this demonstrates at least the need for encryption.

Certificates in SSL/TLS are really used for authentication, which protects against (active) MITM attacks. Depending on how much attention your users are willing to give to this demo, they may or may not need/want to see a MITM attack in the same way (you can try sslstrip or other kits, although it doesn't necessarily demonstrate the same aspect).

If they understand the need for encryption, they'll understand the need for SSL/TLS (HTTPS) on a website. Thankfully, browsers do implement certificate verification anyway when HTTPS is used, thereby protecting you from both passive eavesdropping and active MITM attacks. This makes the usage of a certificate necessary2 (I'm not sure whether your question is specifically on the certificate aspect, or more generally about having to use HTTPS).

Users must never be driven to ignore browser warnings. This also means that they'll need a certificate that's recognised by most browsers by default (this is why an e-commerce website shouldn't use a self-signed cert). PKIs and CAs have their flaws, but they're overall a reasonable compromise for most users.

Then, whether you want to go for an EV certificate or not is up to you. CAs certainly have a vested interest in promoting them. I'm not sure whether this is working, but their marketing is certainly well done and should work for someone who uses their brochures as a starting point without wanting to know too much.

In addition to all this, an e-commerce website should be implemented correctly: no mixed content in particular. Secure cookies are good too. Use HTTP Strict Transport Security if you can.

1. I use that term loosely here, assuming a home router, that's also acts as a hub/switch.

2. I'm not sure any browser supports null ciphers or certificates other than X.509 anyway. They certainly don't with the default settings


What you're describing is the perpetual-motion version of a one-time pad. It doesn't work; the space you have to share the next pad gets shorter with every message. Any given bit in a one-time pad can only be used to encrypt one bit of message.

Let's say you a gave 100KB pad ("key") to Alice. You then send her a 50KB file; this takes 50KB of your pad. You can, if you want, use the last 50KB to send a new pad.*

Alice now has only 50KB of pad that have never been used (the 50KB that were sent under the encryption of the original pad, following the file). She wants to send you a 30KB message, so she encrypts it with the never-used pad and then uses up the rest of that pad - another 20KB worth - to send you a new random pad. The rest of the message is padded out with random bytes to be the same length as the first message.

If Alice were to try using those 50KB for anything real (like more key material), she'd have to re-use part of a pad that had already been used, violating the "one-time" nature of the pad and moving it from "theoretically unbreakable" to "undergraduate homework assignment in the first week of the class" (assuming the new key material were ever itself used as a "one-time" pad).

You now only have 20KB of pad that have never been used. This is after exchanging 80KB of actual messages. It is not a coincidence that these numbers sum up to the original 100KB of pad you exchanged initially. You can't add additional entropy (randomness / unpredictable numbers) into the system except by exchanging further keys.

*As you may have noticed, there's no reason to burn 50KB, 20KB, or whatever of one-time pad sending a new one-time pad. The amount of new key material conveyed is the same as the amount of old key material made useless. You may as well just not use the leftover part of the original pad until you need it for actual message content.

Modern crypto algorithms, which are vastly more complicated than XOR (though they may use XOR as part of the full cryptographic scheme), have ways of "stretching" a key so it can encrypt data longer then itself, without exposing the key (even indirectly) the way XOR does. This is, for example, how all stream ciphers work; they take a key, and from that key they can produce a near-infinitely-long stream of pseudo-random values (that is, they look random if you don't know what they're generated from) that can be used for encryption and decryption (via XOR). The fact that you can never re-use any part of that stream isn't a big deal; it's possible to make it super long, and you can potentially send another key - that will itself get stretched to a long stream - if you get near the end. The total security of this scheme is only (at best) as good as the original key - if the original key was only 40 bits long, for example, it's only going to take at most a bit over a trillion attempts to figure out how to decrypt the entire message including the key used for the next bit - but with sufficiently long keys (128+ bits) that's usually acceptable.

It is worth noting that even modern ciphers are not necessarily as strong as their key length implies. For example, the RC4 stream cipher (which uses 128-bit keys) was recently found to be breakable (at least for the early part of the message) if you can capture a few millions or billions of bytes of messages (plus some guess-and-check, with more guessing needed for less data captured). This is because the "keystream" - the pseudo-random one-time-pad-like-data generated from a given key - was found to be not actually random enough; it has biases (a given bit was not equally likely to be zero or one) that could be discovered by examining enough encrypted text where the corresponding plaintext is known, and using the knowledge of those biases to break the encryption on ciphertext whose plaintext is not known.


Am I encrypting and storing an array of user-details correctly?

Few comments to the provided flow:

Be sure that when you say "Two random initialization-vectors are generated.", they really are cryptographically-secure random.
Symmetric Encryption must be Authenticated Encryption.

Therefore, I suggest you add som MAC (i.e using HMAC). E.g:

1. AES-encrypt: plaintext + secret key + fresh-generated random IV = ciphertext C1.
2. C2 = IV + C1.
3. MAC = HMAC(K , C2) where K is a different secret key independent the first used.
4. C3 = C2 + MAC.