Reverse social engineering (RSE) can mean two things - attack where attacker is trustworthy entity (case 1) or attack where attacker becomes victim (case 2).

When we talk about case 1 there are usually three stages of attack. Stage one is called sabotage where initial damage is made. Stage two or advertise is where attacker gains trust of victim and pursue him/her he is the one who can solve problem they have (made in stage 1). Stage three (assist) is where the attacker gains information/property he needs.

Advantage of RSE is that attack is much harder to discover. On the other hand, main disadvantage is complexity.

The best defense against this type of SE (social engineering) is to use trustworthy companies to do whatever job you need to outsource. Also, background checking on persons who has access to your critical areas can prevent such attacks.

Case 2 is situation where initial attacker becomes victim. However, this types of SE is highly unlikely to happen in business environment and it's mostly found in military (or to use fancy word - counterintelligence).

Example of this kind attack could be so called "Reverse sting" where when attack is recognized victim can preform attack on initial attacker or he can redirect attacker to someone who knows how to counter him. E.g. attackers calls front desk and asks for information X. Instead of giving him information X, front desk redirects call to security department.
Other example of case 2 RSE is where attacker is fed with false data (law enforcement agencies often preform this attack).


What are the differences between Burp and OWASP ZAP?

It is true that both tools are in the same space. Burp is a commercial closed source tool (which can be extended) developed by a commercial company while ZAP is a free open source tool developed by the community.

Both have relative strengths and weaknesses, but as the ZAP project lead I'll let others enumerate those as I'm kind of biased.

Having 2 tools with overlapping functionality is (in my opinion) a good thing, and many security people chain ZAP and burp together to get the advantages of both.


"I did not generate my private/public keys"

You didn't, but your device did.

  "nor can I change them"

I wouldn't be surprised if they add that ability in future  (as it'd just be a case of being allowed to authenticate with your existing key and then request that it be replaced: providing only a new public key at that point)

  Could it be that the private keys were intercepted as they were being sent to users?"

The keys are generated client-side, or so they say...

  "Could it be that Whatsapp kept the private keys, just in case the FBI gets really mad about not being able to access some account and demand cooperation?"

We'll see....

Their paper gives a decent description of what's going on and includes a link to the (open source) protocol library that they use.

However, as with any system, you ultimately have to trust that they're on your side and not the bad guy's (whoever that may be) because if they control the code and the updates to it, then they still have the power to release modifications targeting specific users etc if required... However, much like the Apple vs FBI case, it's really not in the tech companies' best interest to be seen to give in to such demands.


Shop saves credit card data from guest orders

This isn't just bad, this is a disaster. Just knowing the email address of someone allows you to buy stuff using his credit card if he happened to be the unlucky customer of this horrible site.

They are either storing complete credit card data in reversible format, and given that this security disaster was overlooked I wouldn't be surprised if it was stored in plain text without even any attempt at encryption (not that this would change much if the entire server is compromised anyway).

Another less scary possibility would be that they are only storing a reference to the card, whereas the actual card is stored (more securely) on the payment provider's side. In this case, the "buy something on other's behalf with their email" still stands, but at least if they're compromised your card's data doesn't go out in the wild.

If you can see what their credit card processing company is, you should report it to them, they'll quickly cancel his account while they sort it out. And please do expose them on Plaintext Offenders, as this is even worse than plaintext passwords.


Securing media uploading to the cloud from reverse engineering

Since the whole process takes place on the client side, there is no 100% secure implementation of what you are planning to do. If the client can do it, a malicious user can do it as well.

Good news is, that the incentive for an attacker does not seem to be high for executing such an attack. This means, that it is most likely sufficient to make the attack difficult enough, so that the attacker loses interest before succeeding. With a limited profit motive, this threshold should be achievable with reasonable effort.

I recommend the following measures:

Obfuscate the Java client to make reverse engineering more difficult. There are tools available for that, no need to re-invent the wheel.
Sign the video files with a "hidden" key (either in the client code or fetched on demand from a server) and verify the signature on the server-side.
Perform plausibility checks (was the right codec used, is the video 15 seconds long, etc.)
Only allow uploads from registered accounts and ban accounts misusing this feature.
Provide an easy way for users to report misuse, so that you can react in time.

Combining all those measures will make exploitation more difficult, and only the really stubborn attackers will succeed. Given the limited profit motive, that's most likely secure enough.


Here's how I understand LUKS works:

A LUKS volume is encrypted by a single key.
A LUKS volume has a number of keyslots.
Each keyslot stores an encrypted version of the key, protected by a (key derived from a) keyphrase.

Do you want to prevent access to:

The key that's actually used to perform the disk encryption.
The passphrases that are used to encrypt the keyslot.

... and what is your attack model; must the system boot autonomously without a user present to unlock the disk, or must some user/sysadmin still provide a passphrase to unlock the disk, so that the disk cannot be accessed after the entire system is stolen?

For 1 above:

The cryptographic operations that implement disk encryption in Linux are typically performed by the CPU itself, in software, in the kernel. In this case, the CPU must have access to the key in order to implement encryption, It is possible to implement kernel crypto drivers that perform the crypto operations, typically in a separate hardware device. You may be able to implement an SGX-based enclave and expose it to the kernel as a crypto driver, thus hiding the key inside the enclave. However, kernel crypto drivers run kernel mode, and I have not seen any way to launch SGX enclaves in kernel mode. That said, I think it's all just software, so with enough resources, you may be able to implement that. Alternatively, perhaps one could run the enclave in user-space, and implement something similar to FUSE/CUSE to allow the kernel to use that user-space application as the backend for a crypto driver.

For 2 above:

Since using the pass-phrase to derive the disk encryption key from the LUKS keyslot is a small self-contained operation, you could probably adapt the cryptsetup application to run that part of the code inside an SGX enclave. This would allow the crypto operations to occur without observation. However, the enclave would still need to obtain the passphrase for the keyslot from somewhere, which in practice means that the kernel has to pass it in somehow, and thus it could be stolen then. Of course, if you're able to set up a trusted (encrypted, etc.) channel between the SGX enclave and some form of trusted input device, so that the channel cannot be snooped or otherwise tampered with, you may be able to transfer the passphrase into the enclave without anything being able to see it.

I guess overall the simple answer is no. The answer may be yes with a significant amount of effort.


Is It Possible to Implement Rule-Based Access Control on Amazon Web Services?

You mean attribute-based? Yes it is possible. AWS has several ways to do that e.g. AWS IAM which can be used across AWS services. In some cases you can also use resource-based policies (AWS API gateway). Lastly, there are companies e.g. Axiomatics and Savyint who also address this need.


I just found out I have unknowingly been sending a password not using SSL, how likely is it that I have been compromised?

I don't think anyone is able to ultimately quantify the risk. Usually security people are trained to take a systematic approach here which will help you classify the issue:

Asset Value Estimation => as someone said above: what is in your DB? Cat photos or nuclear launch codes?
Threat Modeling => who could be interested in the data and what could they do with it? Would it be of significant monetary value to someone?
Technical Assessment => How probable is it that someone has compromised an ISP device and can sniff your data (this is probably what you are asking for, but in order to quantify your personal risk you need to take into account 1 and 2. The NSA can possibly compromise those devices but they'll just ignore your data if we're dealing with cat photos). I think it is pretty hard to compromise an internet router. Requires a lot of knowledge, criminal energy and probably money.
Are there ways to mitigate the risk => Yes, obviously. Change the password. If you use it on other sites, change it there as well.


EU-GDPR and what I need to conciser when developing a CRM hosted on a Virtual Machine

Yes. You should "maintain measures to encrypt personal data" per article 32 Security of processing which states "Integrate data privacy into an information security policy". I would say that this includes in transit and storage level encryption. The tools you can use to achieve this depend on your overall technology stack.


Very Simple, Facebook IS spyware.

It is also "Consensual" spyware...yeah, it's spying on you, but you agreed to it (even if you didn't read the agreement before checking the "I Agree" box), and it is probably safe to say, you 'enjoyed' the benefits of it, so most people (still) aren't really complaining about it.

As the public's understanding of just how invasive Facebook has become people are coming to terms with what they will and will not accept.

For the most part what it really comes down to is that Facebook is paying attention to what you do in order to target you with advertising for things you will like and to 'grow' it's network.

Think of it this way, if you like, for decades advertisers choose where to place beer commercials, dish soap ads, and other products based on who they thought would be watching TV. There are more beer commercials on CBS during a football game than on ABC during the news (though sometimes the news might make you reach for a beer...but I digress). Facebook has taken this to a new level.

For my part I am pleased that I don't get bombarded with feminine hygiene ads, but do get ads, and even coupons and invitations to events where the food, music and activities are more likely to be 'to my liking'.

More recently, however, Facebook has gotten into more 'censorship'... and IMHO that is bothersome. How much so? each Facebook user will have to decide for themselves. When you walk into the "mall" that is owned by Zuckerberg he does get to decide the rules...if you don't like them, you can always leave. But yes, he is watching.


Difference between an "Information Security Policy" and a "Cybersecurity Strategy"?

There is a massive difference between "Information Security Policy" and a "Cybersecurity Strategy". As the name suggests they are policies and strategies respectively and the management often gets confused between the both. However I believe following points will help explaining the difference.

An information Security policy is an individual document which will:

Enumerate the elements that constitute IT security or information security.
Explain the need of IT security.
Categorize the various types of IT data, i.e. equipment, and processes subject to this policy.
Indicate, in broad terms, the information security responsibilities of the various roles in which each member of the organization may function.
Indicate appropriate levels of security through standards and guidelines.

Where as a Cybersecurity Strategy will comprise of But not limited to

Information Security Policy
Information Sensitivity Policy
Incident Response and Disaster Recovery Plans
Change control procedure
Configuration Standards
Many more policies, guidelines, standards etc which will collectively contribute in how the organization will anticipate/respond to a Cybersecurity threat/incident.

I do understand that some of the elements will be highlighted in Information Security Policy but looking at the bigger picture not everything will be covered. Hope this helps in anyway.


Best way to securely store passwords for local use?

Aside from enforcing a password policy you could store an encryption/decryption key in the TPM. There's a library available here created by MIT.  It was developed as part of the research project on Trusted Computing.

This would ofcourse not cover unauthorized access to the physical machine or if full disk encryption isn't being used.


What is the difference between patch management and vulnerability management?

To find out the differences let's look at what these types of management actually do first.
Patch Management
Patch management includes the planning, acquiring, testing and installing of changes to a software. This can be any kind of software: operating systems, drivers, application software or firmware on appliances. A patch is not necessarily installed to fix a vulnerability, but it can be. Often times it is provided to fix bugs or to update a software to the newest version. In medium size or big organizations - places where you typically have a patch management - there are special software solutions in use to deploy patches to a big number of systems. To give an example: WSUS is such a software.
Vulnerability Management
Following wikipedia vulnerability management is:

the "cyclical practice of identifying, classifying, remediating, and mitigating vulnerabilities", particularly in software.

I want to add, that vulnerabilities are not only found in software, but can also be present in hardware and even in processes or things that are more related to "the physical world", like a door (e.g. a weak lock) or the windows in your office. But a typical vulnerability management will not deal with these things, althouhg it can. This differs from organization to organization.
See also the following definition in ISO 27000:

vulnerability
weakness of an asset or control that can be exploited by one or more threats

Vulnerabilities in software are often eliminated through the installation of a patch. This is why some people say, that vulnerability management is a part of patch management. I wouldn't say so, and here's why: There are sometimes scenarios, where you have to operate systems, that have vulnerabilities that can not be fixed. For example, you have a customer that wants you to run a server with a very old operating system. If the management thinks, this customer is important, you sometimes have no choice, but to accept the presence of these vulnerabilities and might not be able to patch them. You obviously have to install other controls to secure this server somehow. This would be a part of "managing" a vulnerability. (An even simpler example would be: sometimes there is no patch.)
Conclusion
Patch and vulnerability management sound alike but are different. Patch management deals with patches, updates and fixes of software that have to be installed for several different reasons. The rollout of these patches has to be planned beforehand and you need to know which machines need a patch at what time. (If you operate several thousand desktop PCs, this task is a lot harder than it sounds.)
Vulnerability management only deals with security (and sometimes safety) issues of (mostly) software. A lot of the time, these issues can be resolved with a patch, but certainly not always. Vulnerabilities can be present in all kinds of systems and can be eliminated with lots of different strategies. Admins can change the firewall policies, the network setup, buy new hardware, train employees etc. To fix a vulnerability with a patch indefinitely is almost always a very good solution, but it might not be always possible.


How does Yandex Alpha sign me in automatically?

Yandex Alpha automatically imports data from several other browsers whilst installing. More docs on it here.

In the case of Chrome it automatically imports:

Browsing history
Favorites/Bookmarks
Saved passwords
Search engines
Cookies
Extensions
Advanced settings

As you see in this list it automatically imports your cookie store from Chrome so this definitely explains the fact your sessions could be persisted across to the Yandex Alpha browser.

If you wish to not have the import saved down there should be an option to decline the import after the installation has finished. In your case in doesn't seem to have given that option and any reason I could give on that would be speculation.

In terms of whether its a security risk is down to how much you trust the application to have access to these things and not do anything funny with them.


What all content PKCS#7 can have and what is the purpose of each?

You can embed any data within a PKCS#7/CMS structure.
The Cryptographic Message Syntax (which is the new name for PKCS#7) knows the types EnvelopedData for encrypted data and AuthenticatedData for signed/MACed data.

That way, you can create an enveloping signature, thus storing the signature and the signed data in a single file even when the format of your data does not support it.


rainbow table for AES 256 CBC knowing IV, cipher text and plain text

Generating rainbow tables is never the best way to attack a single instance. Rainbow tables are precomputed tables: you do a lot of computations in advance, under the hope that you will be able to apply these computations to several attack instances.

Precomputed tables (rainbow or not rainbow, this does not change anything here) all follow the same pattern:

During precomputations, you "try" N possible passwords and, for each of them, you apply the relevant cryptographic function (in your case, some sort of hash for password-to-key derivation, then symmetric encryption) and store the result (for a rainbow table the storage costs are lowered, but the CPU cost is unchanged -- in fact, it is somewhat enlarged due to the specifics of the rainbow).
At attack time, you look up the observed hash/ciphertext in your table. If the password was indeed one of the N that you processed during the table construction, then the attack works. Otherwise, it does not.

So generating the table costs as much as the worst case of a simple brute force attack: you still pay for hashing all N possible passwords. If you have only one instance to attack, then the direct brute force is cheaper.

In your case, you have some (unspecified) password-to-key derivation scheme h, and what you have to work with is:

    f(p, IV, m) = IV xor AESh(p)(m)

where p is the password, IV is the IV, and m is the first block of the plaintext (the first 16 bytes). If you want to build a precomputed table, then that function f is what you have to evaluate for each password. The resulting table will be applicable only to cases that use the exact same IV and the exact same first block of known plaintext. If either the IV or the known plaintext is different, then not only is the table a poor idea for breaking a single instance, but it also becomes a poor idea in all generality since the table will be usable only once.

A critical point is the h function: the process by which a password is turned into an encryption key. If the h function is a proper password hashing function, the it has a salt, which is generated a new for each password, and this completely defeats precomputed tables, even if the IV and the message are reused exactly.

Even if h is a basic, fast and unsalted hash function (say, a single invocation of SHA-256), then you still cannot reuse existing (rainbow) tables, because you do not have access to the hash output; you only have the ciphertext. The encryption step is sufficient to put your context outside of the contexts for which rainbow tables already exist.

Therefore, if you want to enact your breaking attempts, you will have to implement some brute force mechanism. Roam the Web to gather implementations of AES and of the h function, whatever that hash function is. Put them together in some code that tries potential passwords. Compile, run, be patient.

In any case, such brute force works only insofar as the used password is one of the passwords that you can plausibly try within the limits of your patience. If the AES key is not really derived from a password, but was generated randomly from a cryptographically secure PRNG, then forget it. You won't brute force it.

What you can do depends on the context. For instance, if you have access to a device or system that performs encryption with the key you don't know, but on data that you can choose (a chosen-plaintext attack), then the predictability of the IV (it is always the same, in your description) allows you to perform a brute force on the data (not the key), which, depending on the data, may be very efficient.


Does PKCE replace state in the Authorization Code OAuth flow?

The state is given back by the OAuth2 server in the redirected url, so the client app can verify that the request to open the authorization page was indeed triggered by itself.

The code_challenge is not given back by the OAuth2 server, but the client app must send the belonging code_verifier with the next request to exchange the authorization code for a token. The OAuth2 server can then be sure that it is the same client app which did the first request to open the authorization page.

Even if an attacker listened to the first request and the following redirect, (s)he cannot know the code_verifier, it is never sent over the wire. This makes it impossible to (mis)use the redirect and impersonate the client to get the token.

So yes both are required, the state makes the link between the open-authorization-page-request and the redirect, and the code_challenge makes the link between open-authorization-page-request and exchange-code-for-token-request.


How to detect/mitigate UDP port scan using OpenBSD and pf

Take a look at the sfPortscan rule for Snort.  It is designed to detect traffic to many different ports.  This normally would indicate a portscanning tool like nmap is in use, but it should trigger on the situation you describe.

On the other hand, since you've already detected the attack, I assume you've already eliminated the threat (wiped the hard drive of the infected PC or whatever.)  What are the odds that this same vulnerability will be exploited in the same way by the same malware again?  The good news is that if you install an IDS like Snort, and subscribe to their rules, it'll help continuously protect you against new threats.


A lot of these devices will use Universal Plug and Play (UPnP), a service that runs on many consumer routers and devices, allowing network devices to effectively add port forwarding rules on the router. Many consumers are unaware of this behavior and will thus have their devices exposed to the internet. This is just another example of IoT manufacturers choosing convenience over security.


Integer overflow check not detecting some cases

Your program will work only for x86 as uint32_t is the size of x86 registers. In x64 the registers are 8 bytes and do not consider overflow unless the overflow is above 8 bytes.

   0x40066e <add_u32+40>    mov    eax, dword ptr [rbp - 0x14]
   0x400671 <add_u32+43>    imul   eax, dword ptr [rbp - 0x18]
   0x400675 <add_u32+47>    mov    dword ptr [rbp - 0xc], eax
 ► 0x400678 <add_u32+50>  ✔ jno    add_u32+59                    <0x400681>

The overflow flag was not set in x64 even when my number was 0xffffffff(2**32-1). Also technically scanf("%d", &quantity); would not be the bestway to get input here.


How does john the ripper crack hashes using wordlists?

ssh2john is a utility to convert the key-file into a txt-format that would be suitable for JtR to crack by comparing hashes. There are also other utilities available  e.g. password protected zip-files, keepass DBs etc.
The steps really depends on which mode you use to crack, you could use e.g. word-lists or increment mode. see https://www.openwall.com/john/doc/MODES.shtml


Eve could not just listen to the communication. If you're talking about RSA I assume that Bob's public key is not secret and that even Eve might know it. Then Eve could try to act as Alice by sending messages encrypted with Bob's public key to Bob. If Bob always answers those messages Eve could use the delay until Eve receives the message to perform a timing attack.

Even if Eve can only listen to the communication and Bob sends a reply to Alice every time he receives a message Eve could measure the time between Alice's message and Bob's reply.

Only if Bob does not reply to Alice's messages a timing attack would not be possible. If Bob must reply to Alice's messages Bob must reply only after a fixed amount of time. For example, if it takes at most 100ms to decrypt a message and Bob decrypts some message in 78ms, Bob has to wait 22ms until he is allowed to send a response.


Is there any advantage of using VLAN over guest wifi in this situation

It depends on exactly how the guest WiFi is implemented, but usually it is done by creating another internal network which is strictly separated from the "normal" internal network. Sometimes are also additional restrictions possible for the guest network, like separation between clients inside this guest network (i.e. cannot see and connect to each other) and restricted internet access (like only HTTP and HTTPS).
A VLAN has no advantage here regarding separation, it might even provide less restrictions than offered with the guest network (i.e. no separation of clients inside the VLAN, no restricted internet access).

not be held liable for their internet activity

This can not be achieved, neither with a guest network nor with a VLAN. Both share the same external IP address.  It is not clear from outside if some access to the internet originated in the guest network or normal network.
There is a business model though to repurpose home internet routers as public WiFi hotspots. In this case the provider of this business model will take care of the liability problems. This is usually done by routing the hotspot traffic using a VPN to a VPN exit of the hotspot provider. This makes the hotspot provider the public visible source IP of the traffic and thus any legal problems are directed to the hotspot provider. Sometimes this kind of feature is already available on the routers provided by the local ISP and sometimes it even already enabled. See for example Your Home Router May Also Be a Public Hotspot — Don’t Panic!. Note that access to this hotspot is then usually open to all public, but often restricted to anybody having an agreement with the hotspot provider which might come with additional costs.


How do large companies protect their source code?

First off, I want to say that just because a company is big doesn't mean their security will be any better.
That said, I'll mention that having done security work in a large number of Fortune 500 companies, including lots of name-brands most people are familiar with, I'll say that currently 60-70% of them don't do as much as you'd think they should do. Some even give hundreds of third-party companies around the world full access to pull from their codebase, but not necessarily write to it.
A few use multiple private Github repositories for separate projects with two-factor authentication enabled and tight control over who they grant access too and have a process to quickly revoke access when anyone leaves.
A few others are very serious about protecting things, so they do everything in house and use what to many other companies would look like excessive levels of security control and employee monitoring. These companies use solutions like Data Loss Prevention (DLP) tools to watch for code exfiltration, internal VPN access to heavily hardened environments just for development with a ton of traditional security controls and monitoring, and, in some cases, full-packet capture of all traffic in the environment where the code is stored. But as of 2015 this situation is still very rare.
Something that may be of interest and which has always seemed unusual to me is that the financial industry, especially banks, have far worse security than one would think and that the pharmaceutical industry are much better than other industries, including many defense contractors. There are some industries that are absolutely horrible about security. I mention this because there are other dynamics at play: it's not just big companies versus small ones, a large part of it has to do with organizational culture.
To answer your question, I'm going to point out that it's the business as a whole making these decisions and not the security teams. If the security teams were in charge of everything, or even knew about all the projects going on, things probably wouldn't look anything like they do today.
That said, you should keep in mind that most large businesses are publicly traded and for a number of reasons tend to be much more concerned with short-term profits, meeting quarterly numbers, and competing for marketshare against their other large competitors than about security risks, even if the risks could effectively destroy their business. So keep that in mind when reading the following answers.

If source code were stolen:

Most wouldn't care and it would have almost no impact on their brand or sales. Keep in mind that the code itself is in many cases not what stores the value of a company's offering. If someone else got a copy of Windows 10 source, they couldn't suddenly create a company selling a Windows 10 clone OS and be able to support it. The code itself is only part of the solution sold.

Would the product be at greater risk because of this? Yes absolutely.

External Modification: Yes, but this is harder to do, and easier to catch. That said, since most companies are not seriously monitoring this it's a very real possibility that this has happened to many large companies, especially if back-door access to their software is of significant value to other nation-states. This probably happens a lot more often than people realize.

Internal Attacker: Depending on how smart the attacker was, this may never even be noticed or could be made to look like an inconspicuous programming mistake. Outside of background checks and behavior monitoring, there is not much that can prevent this, but hopefully some source-code analysis tools would catch this and force the team to correct it. This is a particularly tough attack to defend against and is the reason a few companies don't outsource work to other countries and do comprehensive background checks on their developers. Static source code analysis tools are getting better, but there will always be gap between what they can detect and what can be done.

In a nutshell, the holes will always come out before the fixes, so dealing with most security issues becomes something of a race against time. Security tools help give you time-tradeoffs but you'll never have "perfect" security and getting close to that can get very expensive in terms of time (slowing developers down or requiring a lot more man-hours somewhere else).
Again, just because a company is big doesn't mean they have good security. I've seen some small companies with much better security than their larger competitors, and I think this will increasingly be the case since smaller companies that want to take their security more seriously don't have to do massive organizational changes, where larger companies will be forced to stick with the way they've been doing things in the past due to the transition cost.
More importantly, I think it's easier for a new company (of any size, but especially smaller ones) to have security heavily integrated into it's core culture rather having to change their current/legacy cultures like older companies have to. There may even be opportunities now to take market share away from the a less secure product by creating a very secure version of it. Likewise, I think your question is important for a totally different reason: security is still in it's infancy, so we need better solutions in areas like code management where there is a lot of room for improvement.


This is a perfectly fine and viable form of DOS attack.

In your example I would construct such an attack like, say I XSS inject a very popular online page with a lot of hidden traffic to my target page, it could eventually DOS the target page causing a variation of the slashdot effect. This is a form of layer 7 DOS attack.

There is very many examples of layer 7 DOS attacks. It basically means you are exploiting flaws in the application logic which could be anything from sticking the application in CPU intensive loops, making the application consume all local resources or simply having the layer 7 consume all bandwidth.

One more example of Layer 7 DOS could be if I take your username and try to log into an application somewhere many times with the wrong password, essentially leaving your account blocked preventing you from logging in.

Layer 4 DOS can be a TCP flood attack where you send a bunch of TCP SYN packets to a host leaving the host with half open connections, potentially consuming all the resources the OS has available.

Edit: A good example of layer 7 DOS is Slowloris. Quotation on how it works follows:

  Slowloris holds connections open by sending partial HTTP requests. It continues to send subsequent headers at regular intervals to keep the sockets from closing. In this way webservers can be quickly tied up. In particular, servers that have threading will tend to be vulnerable, by virtue of the fact that they attempt to limit the amount of threading they'll allow.


This sort of traffic is pretty normal, and very hard to suppress. You could try to set up an automated system to drop connections from domains / IP addresses that you have no association with, but nowadays, a lot of the attacks are coming from cloud providers that you probably have other critical connections to.

I'd use this traffic as an impetus to review your externally facing systems and confirm that they're patched and as secure as you can make them. If you have the time and the resources, you could consider setting up a honeypot, to help get more info on what type of probes and attacks are being attempted against your systems - that can help you better protect your systems.

And keep reviewing your logs!


The ampersand character is used to separate arguments supplied to the url when multiple argments are used. In your first example the script receives the following arguments

signature=xxxxxxxxxxxxxxxxxxxxxxxxxxxx
url=http%3A%2F%google.com%2F

In your second example the script receives the following arguments:

signature=xxxxxxxxxxxxxxxxxxxxxxxxxxxx
NothingHappend!=
url=http%3A%2F%google.com%2F

As you can see you have added an additional argument, however as the other arguments haven't changed and your script (probably) doesn't use the "NothingHappened" argument it doesn't affect the script in any way.


Polymorphic malware may not do the same actions in the exact same way every time. Antimalware programs will need to be able to interpret the outcome of a set of actions which may not very reliable if the malware author does well with making the actions seem benign and trigger false positives.

Even when boiled down to machine code, you can do the same action in a wide variety of ways. I don't know machine code so I won't write any but for a really simple instance, there are many ways to go about adding two numbers:

x + y = z
x - -y = z
|-x - y| = z
y + x = z
y - -x = z
|-y - x| = z

So even if the program decrypts its own code during runtime to avoid having itself be identified by antimalware software, it can still act in a variety of ways to achieve the same outcome.


Can malware read keychain entries on iOS devices?

I saw this question and decided to do a bit of research into the topic. I'm actually an (ex)Apple Technical Support Senior Advisor for iOS, now working for FileMaker, Inc. which is a subsidiary of Apple. My iOS device is jailbroken. So I decided to do some sniffing around the filesystem with iFile to take a closer look at the keychain application, where is stores the keys and how it handles them.

Now, before I give my answer, I do want to make clear that 'malware' on an iOS device is nearly impossible. That said, your answer actually depends on whether you're using iOS 4.x (or later) or not and (get ready for this) whether you have a pass-code on your device or not.

When there is a pass-code on your device, the OS actually treats that as a second layer of security within the keychain. More specifically, it is an encryption key.

The answer is yes. But only in the scenario where you have a weak enough pass-code to decrypt.

Here is a link to the page that confirmed this:

https://stackoverflow.com/questions/3558252/ios-keychain-security

I would like to refer you to pepsi's answer to a very similar topic on this page. He provides links to a study that has been done and also explains the details of the topic.


What is an appropriate auditing standard for a law firm?

Both answers above are bang on the money, but I'd just like to add the following caveat.  I run a regulatory services company and I got us certified to ISO 27001.  The one thing I would communicate to anybody thinking of becoming certified is to remember that being certified to a standard is not like acquiring a magic talisman that wards off all evil (and lawsuits).  Because these standards are not compulsory and the certification is voluntary, your protection in court against legal redress always boils down to due diligence.

In other words, if a magistrate thinks that you've given confidential information undue exposure then you are going to be screwed, regardless of whether you have ISO 27001 or not.  However the point of certification, and this is really important to remember, is that to get it you must be totally methodological and careful and list all of your liabilities, and assess them, and address these with remedial actions.  This means that at the end of the certification process your company is going to be a lot more vigilant and 'hardened' to borrow a sysadmin term.

I'm biased towards ISO 27001 as opposed to SOX etc. because it's generally accepted that the ISO covers the requirements for practically all the other standards.  PCI has a few quirks, such as separation of processing facilities and other standards may be prescriptive about particular things, but you can still impliment these within an ISO framework, and you'll probably do a better job of it at the same time.

One final point that has also been mentioned tangentally already, is that a good risk-assessment based system will save you money.  Before I started doing it, I wanted the most expensive firewall, the smartest card reader, the perfect multi-site failover and would sweat over specifications.  But when you've done a proper risk assessment, you start to realise that actually you are never going to totally remove risk, so by the law of diminishing returns you are better off spending your money wisely than aiming for the ultimate protection.  At the end of the day, one you're biggest vulnerabilities is your employees.  So save your company money and organise some staff training sessions.


Is this "Domain Registration Service" email a scam?

Yes, this email is a scam. Ignore it!

I work at a major web hosting firm, and our customers receive these emails on a frequent basis. There are a number of characteristics that are visible from this perspective which confirm that they are a scam:

The emails are never sent by a recognizable, reputable domain registrar. Most of them use generic names, such as "Asian Domain Registration Service" in your email, "China domain registration center", or the like. The emails never have senders, headers, or signatures which explicitly link them with a registrar, and there is usually not even any accredited registrar with the right name.
The domain registrations are never being made by a recognizable company or organization. You've obscured the relevant name as "Some Other Corp, Ltd" here, but the names are often generic ("Foo Trading Co") or incomprehensible ("FANGSHI Co"). Attempts to identify or contact them are never successful (or find only unrelated companies).
They are frequently sent in relation to a domain name which would be meaningless under an Asian top-level domain. Many of them involve domain names containing names of people or locations — for example, these types of emails might claim that a Chinese trading company is attempting to register the domain "johndoe-hardware.hk" or "newyork-blahblah.asia". There is no apparent logic to these registrations.
Despite supposedly coming from many different registrars, these emails always follow a very similar format. There are multiple templates, so the wording can vary, but the formula is always precisely the same. In particular, the domain names being registered are ALWAYS only under "Asian" TLDs (typically .asia, .cn, .hk, .tw, and .in), never under any other TLDs. Additionally, many of these emails also claim that the bundle includes an "Internet keyword" or "Internet trademark", which doesn't even exist.

We have advised a very large number of our customers to disregard these emails, and not once has any of the domains mentioned actually been purchased by the individual or company that was supposedly attempting to acquire them. None of the people who have written about receiving these emails online has had this outcome, either. Everything points to these emails being a widespread scam!

Further reading:

Canadian Trade Commissioner Service: Domain name registration in China
SCAMWatch (Australian Competition & Consumer Commission): Think carefully about unsolicited offers to register domain names overseas

I can only post two links, but you'll find a bunch more if you do a Google search for "Chinese domain scam" or something of the sort. It's widely attested.


Is knowing someone's card expiration date a means of finding info about them?

No. The date on the card is set by the issuer. So the length of time can be different from vendor to vendor. Even might be different depending on the card or account type. So you would have to know exactly what that time frame is to get the issue date. The issue date is also not a security question at financial institutions to verify the identity of a customer. Whereas the expiration date itself might be. But not enough on it's own. So phishing would be an unlikely use for the date unless you already had additional information about the customer. (IE Last 4 of social, last deposit amount, account number, other information about that card, etc) All of which are impossible to get from the date.


Self-signed SSL certificate on chromebook (and android)

the common name cannot be an IP address. You may put IP addresses into the subject alternative name section, but as IP address not DNS
the certificate might need a CA=true property if you want to import it as authority, simply self-signing might not be enough. You might still be able to import it and it will show up, but does not work.
it failed for me for Firefox and Chrome until I've put also extended key usage of "TLS Web Server Authentication" in the certificate and also Netscape Cert Type 'server', which seems to be missing from your certificate. After I've added both it also works with Chrome on Android.

This is the certificate which works for me:

Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number: 1893982163 (0x70e3dfd3)
    Signature Algorithm: sha256WithRSAEncryption
        Issuer: CN=foo.com
        Validity
            Not Before: Apr  7 18:47:17 2014 GMT
            Not After : Apr  7 18:47:17 2015 GMT
        Subject: CN=foo.com
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
                Public-Key: (2048 bit)
                Modulus: ...
                 Exponent: 65537 (0x10001)
        X509v3 extensions:
            X509v3 Subject Key Identifier:
                32:04:C3:BF:60:46:D4:4A:90:2F:CC:55:F1:B1:7D:B7:BF:7A:61:4B
            X509v3 Authority Key Identifier:                    keyid:32:04:C3:BF:60:46:D4:4A:90:2F:CC:55:F1:B1:7D:B7:BF:7A:61:4B

            X509v3 Authority Key Identifier:
                DirName:
                serial:70:E3:DF:D3

            X509v3 Subject Alternative Name:
                IP Address:192.168.178.4
            X509v3 Basic Constraints: critical
                CA:TRUE
            X509v3 Key Usage: critical
                Digital Signature, Certificate Sign
            X509v3 Extended Key Usage:
                TLS Web Server Authentication
            Netscape Cert Type:
                SSL Server
    Signature Algorithm: sha256WithRSAEncryption
        ....


How do I report a vulnerability to a large organization that doesn't believe it has a problem?

Since you are a customer of the company it might give you some more options.  A few things worth considering:

Write a letter to the CEO of the company.  Make a copy of the letter
and send it to the person you spoke with as well as their manager.
Notify the press if you think you can find anyone who would be interested in the
story.
File a complaint with the Better Business Bureau (if you are in the US) and send it to the CEO
Take your business somewhere else and tell them why you are doing it.

Honestly I think there is very little chance any of these will work, but it sounds like they are shining you on right now so your options are limited.


ssh-keygen won't print '=' symbol in sha256 of pubkey, but python will

base64 uses equal signs for padding if the number of encoded bytes is not a multiple of 3.
However, the padding is not always  mandatory and its use varies between implementations:

  In theory, the padding character is not needed for decoding, since the number of missing bytes can be calculated from the number of Base64 digits. In some implementations, the padding character is mandatory, while for others it is not used.

(Source)

For example, since this string has only 7 bytes, == is appended to pad the value to a multiple of 3:

$ echo -n "1234567" | base64
MTIzNDU2Nw==

So both variants are correct. If in doubt, use the padded one.


I'll answer my own question since I haven't seen this practice be encouraged in various SDKs and code samples.  Here is my theory:

Upon clicking the "sign in" button on the Relying Party (RP), two things should happen:

Write a random value to a SECURE HTTPOnly domain cookie
Then have the IDP redirect back to https://www.host.com/account/signin?csrf=myrandom
 where "myrandom" equals the value within the cookie.
When the OpenID process signs you in, then it will POST to the above URL, you can then grab the CSRF string, and compare that to the cookie.

Let me know if you see any flaws in this approach


How can I identify which computers a USB drive has been used on?

Removable devices including USB sticks don't store this information.

You can perhaps find some specific products which implement an auditing / logging technology to remember the number / type of devices it has been plugged in, but if your specific device don't implement it then you can't.


It's not called Flash Drive By, but Drive-By Download, and yes, it's basically downloading malware just by visiting an infected website. Usually drive-by downloads work by exploiting a browser vulnerability (or a vulnerability in plugin like Flash or Adobe Reader), which leads to remote code execution triggering the download of malware.

Unfortunately drive-by downloads are getting more and more popular, especially that many legitimate websites get infected by adding a malicious Javascript code to their pages. That in turn usually happens with SQL injection and/or XSS. So, basically, a web application vulnerability in a legitimate website may lead to system-level exploitation of clients that visit it.

You can learn more about Drive-By-Downloads, the mechanism of infections, the statistics etc. in the following OWASP presentation.


For the 2010-3749 issue, presuming you're looking at this exploit it doesn't really look like a canned exploit, more like an explanation of the issue. It would require for the application in question to make use of the vulnerable function for it to be exploitable.

Indeed, having a quick look through some of the issues that you've linked they look to be PHP language level issues. With this kind of problem, unless the codebase on the target system makes use of the vulnerable functionality, it may well not be exploitable. It could well be that Nessus is reporting vulnerability based on a received HTTP header which indicates an old version of PHP in use.

This doesn't necessarily mean that that the system in question is actually vulnerable

In addition to the sites you've mentioned I tend to look at cvedetails.com for any metasploit modules which may target the affected issue.

you could also try secunia.com and search for issues based on the product, as opposed to looking at language level issues.


Is Facebook allowed to sell/give your information away to anyone willing to buy it?

There is a classic phrase:

  "If you are not paying for it, you're not the customer; you're the
  product being sold"

In case of companies' liquidation, they openly sell their user databases on the internet as one of the liquidated assets.

Well, think this way. If Microsoft bought , say, Skype, had Skype sold its user database and what is the sense/value of Skype, or Facebook, without their user database?

Besides, online service companies, like Facebook, are functioning on the basis of license (terms of service, etc.) agreements with users not contracts.
That means that if one of the sides breaks it, this would constitute violation of copyright law not contract law.

Update:
Here is an excerpt from

Hundreds of websites share usernames sans permission.
Photobucket, Wall Street Journal, Home Depot take liberties with your personal info
http://www.theregister.co.uk/2011/10/11/websites_share_usernames/

"Home Depot, The Wall Street Journal, Photobucket, and
hundreds of other websites share visitor's names, usernames, or other
personal information with advertisers or other third parties, often
without disclosing the practice in privacy policies, academic
researchers said.

Sixty-one percent of websites tested by researchers from Stanford Law
School's Center for Internet and Society leaked the personal
information, sometimes to dozens of third-party partners. Home Depot,
for example, disclosed the first names and email addresses of visitors
who clicked on an ad to 13 companies. The Wall Street Journal divulged
to seven of its partners the email address of users who enter the
wrong password. And Photobucket handed over the usernames of those who
use the site to share images with their friends."

Your phone company is selling your personal data (CNN, Nov 1, 2011)

"Verizon (VZ, Fortune 500) is the first mobile provider to publicly confirm that it is actually selling information gleaned from its customers directly to businesses. But it's hardly alone in using data about its subscribers to make extra cash"
Facebook is blurting out your private information
no date but comments start on Oct, 2010, and the author regularly tweet this article (Nov, 2011)

"... the moment you land into one of their [Facebook's] “trusted partners” sites, your personal information has just been given away"

I could not resist from visualizing the comment by Hendrik Brummermann from this answer here pointing to this image found on the web:

as well as to answer that answer by quote of "Privacy Zuckering" definition:

"The act of creating deliberately confusing jargon and user-interfaces which trick your users into sharing more info about themselves than they really want to."
(As defined by the EFF).

The term "Zuckering" was suggested in an EFF article by Tim Jones on Facebook's "Evil Interfaces". It is, of course, named after Facebook CEO Mark Zuckerberg


I have added an update to SQLiPy that will hopefully be incorporated into the BApp store soon that allows the user to toggle the HTTP method/verb.  If you don't want to wait on the update in the BApp store, you can get it at https://github.com/codewatchorg/sqlipy.  The latest version is 0.5.2.


Using a Cryptovariable with an API Designed for Human-Generated Passwords

Computing entropy for a randomly chosen password can be broken down to a simple rule that can be used in virtually all cases, with some caveats.  It's the log2() of the password character set space raised to the power of the password length.  So, with a completely random password where all characters are independent, this is an easy calculation.  E.G., For a password that is 8 characters long and composed only of uppercase English letters, it is: log2(26^8) or ~37.6 bits of entropy.  Another slightly more verbose way to express this is: log2(26*26*26*26*26*26*26*26).  If we were to add a constraint to our password, perhaps it must be four uppercase characters and then two digits, a randomly generated password will have log2(26*26*26*26*10*10) bits of entropy.  (~25.4 bits)

So, in a more complex case like yours, you have to determine how many characters are available for each successive position in order to determine the password space and thus, the entropy.  The condition prohibiting repetition means that you cannot actually know before hand the entropy of a specific password, because the character set to chose from will be constrained by characters already chosen...So you can only calculate the minimum entropy should the characters randomly chosen maximally constrain the character space for later characters.  I don't actually want to work out this specific calculation but generally, to prevent any repetitive sequences, you need only limit the character space by the last character chosen (so you don't get bb) and if there are any previous incidents of the previous character, the characters that follow those incidents.  (So if to this point the password is abcdbeb, you would need to exclude b, c, and e from the character space for the next character.)  As you can see, this means that as the password grows in length, the available character space is not only going to shrink, but its size will only be known after the previously chosen characters have been examined.

So, the super simple method to determine minimum entropy with a maximum margin of error I mentioned in the comment is to simply exclude each character as it is used.  With no possibility of a character being used twice, there is no possiblity of a repeating sequence.  With a character space starting with 64 characters, and a password that is 48 characters long, this is log2(64*63*62*...*16) which is a massive ~249.7 bits of entropy.  So, since we know that given your specific constraints, the entropy of your passwords will be higher, you have a huge safely margin, and there's no realistic chance of a successful brute force attack.

As an aside, if you had no constraints, and randomly chose 48 character passwords from a set of 64 characters, you would have had 288 bits of entropy.


Key Derivation Functions

What you are describing is really no different than the key derivation functions (KDF) already used in many encryption/password hashing contexts.  Plenty of KDFs have a configurable cost parameter that can allow you to increase or decrease the total "CPU Time" (I'm simplifying) needed to generate the actual key from the password.  In this case what you call the key (i.e. "pineapple") would effectively be a password that is run through a KDF to generate a cyrptographic key, which is then used for encryption/decryption of the data.  You would never have to send the password along to the server - just the generated key, which is always built using the KDF on the client side.

Cost factors

That last bit (generating the key client side) would be important, because for what you are talking about the cost factor would have to be very high.  That might be a detail you are missing.  The only way to both let people share a password and even guess passwords, but not be able to effectively brute force random passwords, is if the KDF is very slow.  Normally the cost parameter is tuned so that the time to generate the key on "good" hardware is, for instance, 0.2 seconds (I'm over simplifying and skipping lots of details for the sake of example).  The reason you pick a timescale like ~0.2 seconds for key generation is to balance the desire to make brute force expensive, but also make it so that your system can actually perform the necessary operations itself in the timescale that users are willing to wait (i.e. no one wants to wait 30 seconds each time they login).

The trouble

However, even if an attacker can only check one "password" a second, there are still 86400 seconds in a day, which means that you can get through the entire oxford english dictionary (~170,000 words) in just a few days.  As a result, to stop someone from feasibly brute-forcing common dictionary words, you're talking about a key generation process that would have to take at least a few minutes, and I doubt that would stop a dedicated attacker (especially if they have top end hardware that can run the KDF in less time).  If you do that though, that means that your legitimate users will also have to wait those same minutes before they can get results out of your system.  After all, there is no way to differentiate between a legitimate user of your system and an attacker, so the only way to slow down attackers is by slowing down everyone.  So to do what you want to do you will have to slow down your KDF so that it takes some "long" amount of time to run, but it is quite possible that the level of "slowness" you need to secure to the level you desire (i.e. stopping brute force of common dictionary words) will be so slow that your users are unwilling to wait for your system to do its thing.  Ultimately, finding that balance between usability and security will be up to you and your users.

A possible solution

You can fix some of the trouble by using server-side throttling instead of making an arbitrarily large cost factor.  Imagine if the API calls where the user says "give me data for this key" does not immediately return results but instead generates a queued request that only responds after X period of time.  This would allow you to block brute-forcing regardless of what level of hardware the attacker has access to, would not slow down your server with a lengthy KDF process, and also would not penalize users with slow hardware.  The disadvantage of course is that it is a server-side control, so if your database leaked a hacker could go to town on brute-forcing at the speed of their hardware.


Wireless card simultaneously in monitor mode and managed mode

You can use one card in monitor mode to deauth clients and capture traffic at the same time but the card itself can only be runned in one mode because the mode is kind of a binary option.

What you can do is using the internal card of your laptop in managed mode to connect to a network and the attached wifi card in monitor mode to capture and deauth clients. That would be possible.


Injecting alert("1") to OWASP Juice shop doesn't work

I went ahead and tried to determine what endpoint in the OWASP Juice Shop application you are injecting your payload into. Please correct me if I am wrong, but it appears that the payload is injected via the search field.

This appears to be DOM-based XSS and not reflected XSS. This is important to note since the payload is passed on to the innerHTML method:

{{"TITLE_SEARCH_RESULTS" | translate}} -

 does not execute when injected via innerHTML as stated here:

  script elements inserted using innerHTML do not execute when they are inserted.

Instead, I would recommend using payloads such as  and .


There was not a version for ASP.NET 1.1.  The AntiXss library is open source though, so you might be able to find the earliest version and try to convert to 1.1.


Maybe look for floppy disk images. Such as this one: http://project.honeynet.org/scans/scan24/


You need to specify -crl_check (and spell verify correctly) AND have both the CA cert and the (applicable) CRL in your truststore. There are two ways to do that:

concatenate cacert.pem and crl.pem into one file and use that for -CAfile.
put or link the cacert PEM file in a directory using the name $hash.0 where $hash is the hash of the cert subject (which for a root cert is also the issuer) as output by openssl x509 -noout -subject_hash -in $cert; and put or link the CRL PEM file in the same directory using the name $hash.r0 where $hash is the hash of the CRL issuer as output by openssl crl -noout -hash -in $crl (which here will be the same as the cert); and use that directory for -CApath. (In a more general case where you have many certs and/or CRLs and there are hash collisions, you increment the 0 to 1 etc.)

Approach 2 is probably the one you have seen referenced, but note it is not the cert nor the CRL as such that is hashed. Depending on whether you're using the source distro of openssl or a packaged build, on Unix it may provide a script c_rehash which sets up symlinks for approach 2; on Windows AFAICT you're on your own, and doing it by hand is rather a nuisance (but possible).


Should I generate a lot of random serial keys and pick one for each registration or generate 1 for each user?

Randomness and uniqueness are different concepts. Few random values from a large entropy space are generally all different but there is no guarantee on that. If you need both, I would split the key in two parts: one would be a simple sequence (uniqueness is guaranteed) and the latter would be produced by a random generator.

The size of those parts depends on your requirements: estimated number of keys give the first part, robustness to brute force attacks give the second one.

If the size of key must be limited and if you still want high brute force resistance, you will have to only use a random value and store all produced ones. Then when you need a new one, you just loop on random values until you find a unique one.

IHMO producing a bunch in advance or one at a time is just an implementation detail. If you realize that producing a new key could take too much time and lead to poor performances, it can make sense to always have a small number of keys pre-calculated in the application. You could use a background thread feeding a queue here...


Why is cell phone reverse lookup still so impoverished?

It's not obscure, it's been monitized. If you're willing to pay for the information it's generally available.


The class of malware which prevents itself or other programs from being seen is called rootkits.  They work by replacing key system calls that are used to detect what is going on in the system.  For example, when you go to Task Manager, Task Manager asks Windows for a list of programs running on the system, but suppose that another bad program was able to replace that request with one that said "what programs are running other than "my bad program".  That's basically what a root kit does.

Done properly, it makes it so that no matter how you try to ask for the information that would tell you what is going on, it gets intercepted by the bad code that says nothing is wrong.  There isn't any way to tell for sure if you have one and there isn't any way to tell for sure you've cleaned them all if you've been infected by one.  This is part of the reason for the "nuke it from orbit" philosophy that you may have heard around here saying that you should completely reinstall a system if it is compromised by anything more than the most simplistic malware.

The easiest and most effective way to detect a root kit is to boot from something known as a LiveCD.  It's an operating system on a CD or DVD that can boot up and scan your hard drive from a known good configuration.  There are a few things out there that can get around even this by infecting the actual hardware components themselves, but those are still (thankfully) exceedingly rare and fairly device specific.

As another aside, there are also key loggers that are actual pieces of hardware that sit on the line for the keyboard and can detect (or even alter) all keystrokes without having any software running on the system.  These are also exceptionally rare.


It is as easy to spoof the sender of the email as you can lie about the sender on the envelope of snail mail. It is also not only easy but heavily used: the majority of spam and phishing mails use address spoofing. The only real way to be sure about the sender is if the sender signs the mail and the recipient verifies the signature. Common solutions for signing (and encrypting) are PGP and S/MIME.

There are other anti-spoofing techniques like DKIM or SPF but these work at most at the level of domains and thus can not detect if somebody inside a domain is spoofing another mail account inside the domain. If protection at the domain level is all you need then DKIM should be preferred to SPF because it signs outgoing mails using cryptography. This signature then can be checked inside supporting mail clients. With SPF instead the receiving mail server must check that the mail comes from the expected IP addresses and the end user can not verify this. But you could also use both DKIM and SPF at the same time.


Is the security of this .net application flawed?

The structure of a DXF file is somthing like this:

You know it so go to the end of answer

ASCII versions of DXF can be read with a text-editor. The basic organization of a DXF file is as follows:

HEADER section – General information about the drawing. Each parameter has a variable name and an associated value.

CLASSES section – Holds the information for application-defined classes whose instances appear in the BLOCKS, ENTITIES, and OBJECTS sections of the database.Generally does not provide sufficient information to allow interoperability with other programs.

TABLES section – This section contains definitions of named items.

Application ID (APPID) table

Block Record (BLOCK_RECORD) table

Dimension Style (DIMSTYPE) table

Layer (LAYER) table

Linetype (LTYPE) table

Text style (STYLE) table

User Coordinate System (UCS) table

View (VIEW) table

Viewport configuration (VPORT) table

BLOCKS section – This section contains Block Definition entities describing the entities comprising each Block in the drawing.

ENTITIES section – This section contains the drawing entities, including any Block References.

OBJECTS section – Contains the data that apply to nongraphical objects, used by AutoLISP and ObjectARX applications.

THUMBNAILIMAGE section – Contains the preview image for the DXF file.

END OF FILE

The data format of a DXF is called a "tagged data" format which "means that each data element in the file is preceded by an integer number that is called a group code. A group code's value indicates what type of data element follows. This value also indicates the meaning of a data element for a given object (or record) type.

Reference: Wikipedia

You want to send this data from your local software to the server, an easy crack is sniffing, the cracker write a little program that can convert above structure to DXF file, the crack software will be sit on the line between local program and the server, captures each data that is transferred and stores it in a file, no need to the server.


How to safely use a Key Derivation Function to secure private data - need guidance

"Is this secure enough?"  This depends on who you're defending against.

In theory, it looks like it'll stand up to non-TLA attackers reasonably well, although decrypting might be a bit tricky, as you don't seem to be storing the encryption IV anywhere.

In practice, it's got a major security hole.  No real-world user is going to memorize the KDF iteration count.  It'll get written down somewhere, and since the user is writing it down, they'll probably put their username and password right next to it.


How to detect the so-called "undetectable" Gameover Zeus?

The media are in a feeding frenzy over this. However, the malware in question is several years old. This started I think with the FBI blowing their own trumpet over taking over a botnet (that had been working for several years).

Then the UK's National Crime Agency decided to use it as a public awareness campaign to try and get people to improve the safety and security of their PC's.

Then the press got it and did their usual thing of totally twisting it out of recognition.

Indeed, the later variants of this malware are, at least to a degree, not even dependent on their command and control servers. They are capable of talking peer-to-peer.

So the risk is inflated by the press. However, that isn't to say that this type of malware doesn't present a real and present danger to anyone using the Internet - it does.

So the usual mitigations should be applied:

Good anti-malware software with rapid updates (the Microsoft AV seems to have fallen off the edge of acceptable recently) - Avast, etc.
Limits on running executables - this may well be the best protection all round. Unfortunately, it isn't easy to achieve outside the enterprise & even in the enterprise, it does annoy people! Only recognised and authorised executables should be able to run.
Outside the enterprise, sensible precautions are running Microsoft EMET and running as a standard user not a user with admin rights.

An occasional sweep with alternative anti-malware tools and rootkit detection tools may also be sensible though many of the vendors of what were just AV tools now include additional checks as well.

Oh, and inside an enterprise, there should also be additional checks at network boundaries by using threat management tools which can detect suspicious activity both coming into and going out of the network and blocking & reporting it.

Finally, the malware in question is most certainly detectable by the right tools. A quick search will reveal that.


Hash list for practicing password cracking

You've got the right idea - this is a great way to learn.

For beginning and intermediate cracking, the best general password lists are actual lists of passwords - those found in leaks with large general user bases. And the best general practice hash lists are the hashes from public leaks.

Your best "bang for the buck", in my opinion, is the hashes.org "left" and "found" lists (the "founds" are combined in multiple archive files at the bottom of the page). The older lists are "frozen" after the year is over, so once you download the older ones, you only have to download this year's once in a while.) You'll also see some "junk" archives listed there. They are less efficient, but can also be interesting to play with after you exhaust other attacks.)

For benchmarking, the Weakpass wordlist index compares wordlist efficacy using the best64 ruleset against a few targets. In that list, you can see that general efficiency compared to the size of the list is quite good for the combined hashes.org list. (But download it directly from hashes.org to get the newest).

Beyond hashes.org, all other human-generated strings are great fodder, including:

wordlists from Wikipedia, Wikia, etc. (See sraveau's work on this)
Usernames and email address (left-hand user portion) from leaks
lists of given names and surnames (there is a Facebook corpus out there)
dictionaries in foreign languages (preferably UTF-8 encoded)
street names, band names, song names
predictable already-memorized sequences (dates, phone numbers, SSNs ...)
etc. (anything else people already remember)

See also SkullSecurity's password page for some good leads, and g0tmi1k's attack efficiency testing, which sounds similar to what you're planning.


The development platform has as close to nothing to do with the security of your app. It might, if your development machine is not properly secured or directly targeted.

The number one rule you have to follow is to not implement your own crypto. Use well known and tested libraries.


password complexity and policies from the users' point of view

There are now very good guidance for policies that are foundationally good for users. Most of the requirements you state in your question are now antiquated.

Best: use a password manager! Let software generate and enter the password for the user. No memory required and the password can be generated at maximum complexity (entropy/randomness, whatever you use to understand password strength)

But if you need to generate your own passwords:

First: stop requiring that users change their passwords so frequently. Most guidance suggests never requiring a change until there is a specified need to change (as in never, except when the account is suspected of being compromised). There is some debate on this point, but some admins only go so far as requiring an annual change.

Second: there has been encouragement for a long time to stop using the term "password" and using the term "passphrase". Length is far "stronger" than complexity. So, create a sentence: Word word word word. There's upper, lower, and special characters (space and a period). Is this perfect? Absolutely not! Is it strong "enough" and user-friendly? Yes, for most use cases. Admins and senior execs should be using far better passwords (see password managers above).

Third: [this is where the community will skewer me] require Two Factor Authentication and if used, relax the length and complexity requirements. I had never thought about this until I taught security awareness to Special Needs teachers who came up with this idea during class. It can be difficult for some differently abled and the very young to enter a complex or long password. If 2FA is implemented correctly, the password can be very simple, and yet secured by 2FA. Even if someone else needs to enter the password for the user, the 2FA token leaves with the user. Even if you do not loosen the complexity requirements, use 2FA everywhere you can.

All these things (except relaxing password complexity if 2FA is used) have been commonplace password guidance around the world for a couple years:

UK:
https://www.ncsc.gov.uk/guidance/password-guidance-simplifying-your-approach

USA:
https://nakedsecurity.sophos.com/2016/08/18/nists-new-password-rules-what-you-need-to-know/

Microsoft:
https://www.semperis.com/microsoft-upends-traditional-password-recommendations-with-significant-new-guidance/


Are there differences between McAfee quarantine and other AV quarantining mechanisms?

See here - https://kc.mcafee.com/corporate/index?page=content&id=KB72755&pmv=print

Quarantined files (.BUP format) are an archive file containing two files - the quarantined file "file_0" and a details file containing the original file name / location.

Both have their data xor'd with the key 0X6A.

When quarantining McAfee will kill the running process then xor/archive the file to ensure it cannot be executed (without knowledge of the McAfee archieve process).


Why does arp spoofing on a local network 'break' internet access for the victim?

"It breaks cause you dont forward the packets"

Basically in an ARP spoof attack you tell the victim you are the router and to the router that you are the victim.So all the traffic basically flows through you.But you need to enable ip_forwarding to actually transmit packets from your device to the router,that is why it "BREAKS" the internet for the victim,cause you are not forwarding the packets to the router and back.


Protecting critical state infrastructure from the aftermath of a nuclear blast

The Internet at large is designed to resist nuclear blasts. At least, it was a design goal of its immediate predecessor, ARPANET.

There is no secret: to survive loss of components, you must have redundancy. In the context of nuclear blasts, this means that there must exist several paths for data between any two machines, and the paths should be as geographically separate as possible. Mathematically, given an assumed blast radius r of 50 miles (for a nuclear-powered EMP, this is a rather low estimate), and two machines A and B and two paths between A and B, then the following should hold: for any two points M and N where M is on path 1 and N is on path 2, and the distance between M and N is less than r, then either M or N (or both) is no farther than r from either A or B. In plain words, the two paths never come closer than 50 miles from each other, except at both extremities (the two paths necessarily join at A and B).

The packet routing nature of ARPANET, then the Internet, allows for such redundancy. Extra points to radio links, in particular satellites: the link between a base station and a satellite cannot be permanently disrupted by a nuclear blast in between. The blast may induce a high ionization of the upper layers of atmosphere, so communications may be temporarily jammed, especially for longer wave lengths; satellites work in the GHz band and should have less trouble than, say, FM. Also, geostationary satellites tend to be relatively high on the horizon (at least from southern USA -- much less so from, say, Moscow) so getting a blast between a base station in Atlanta and a geostationary satellite which is roughly over the Americas entails detonating the thing over US territory, at which point Atlanta itself is in big trouble.

Transoceanic cables should also be fine: 3 miles of water are a Hell of a shield. And they offer lower latency than geostationary satellites (the ping time with a remote server through a geostationary satellite cannot be lower than half a second, because 4*36000 = 144000 km); latency is a problem for flying drones. Lower-altitude satellites are more difficult to use (from the point of view of a base station, they move a lot and often go beyond the horizon) and are in range of Anti-satellite missiles.

Optic fiber is more resilient to EMP than copper links, and the US military have studied that for more than 35 years. The weak part of an optic fiber link would be repeaters: the devices which pick up the signal and re-emit it stronger. You need some of these in any long-range cable. But at least this reduces the problem to building anti-radiation bunkers at regular intervals.

Actually, a bigger problem may be electricity. An EMP will imply high surges in the grid. For instance, the US grid has trouble resisting bad weather.

And, of course, redundancy of network links is not sufficient: you also need to duplicate the servers (data storage, computing elements). You already need to do that to survive floods and earthquakes and even simpler events like a server room burning down. EMP resistance is just more of the same, on a slightly larger scale.


The most secure external hard drives on the market

Hardware encryption meeting the standards for FIPS 140-2 certification is validated by the National Institute of Standards and Technology (US Dept of Commerce).

These devices conform to some of the highest standards for physical and Cryptographic security. Reliance on purely a vendors trust is not needed if you verify the product is listed with NIST as validated.

One of the most common FIPS 140-2 devices used in industry is the Ironkey and has been arround for many years.


Why doesn't Linux randomize the address of the executable code segment?

Although the details greatly vary between architectures, what I say here applies equally well to 32-bit x86, 64-bit x86, but also ARM and PowerPC: faced with the same issues, about all architecture designers have used similar solutions.

There are (roughly speaking) four kinds of "accesses", at assembly level, which are relevant to the "position-independent" system: there are function calls (call opcodes) and data accesses, and both may target either an entity within the same object (where an object is a "shared object", i.e. a DLL, or the executable file itself) or within another object. Data accesses to stack variables are not relevant here; I am talking about data accesses to global variables or static constant data (in particular the contents of what appears, at source level, to be literal character strings). In a C++ context, virtual methods are referenced by what is, internally, function pointers in special tables (called "vtables"); for the purposes of this answer, these are data accesses as well, even though a method is code.

The call opcode uses a target address which is relative: it is an offset computed between the current instruction pointer (technically, the first byte after the argument to the call opcode) and the call target address. This means that function calls within the same object can be fully resolved at (static) link time; they don't show up in the dynamic symbol tables, and they are "position-independent". On the other hand, function calls to other objects (cross-DLL calls, or calls from the executable file to a DLL) must go through some indirection which is handled by the dynamic linker. The call opcode must still jump "somewhere", and the dynamic linker wants to dynamically adjust it. The format tries to achieve two characteristics:

Lazy linking: the call target is looked for and resolved only when it is first used.
Shared pages: at most as possible, in-memory structures should be kept identical to the corresponding bytes in executable files, to promote sharing across multiple invocations (if two processes load the same DLL, the code should be present only once in RAM) and easier paging (when RAM is tight, a page which is an unmodified copy of a chunk of data in a file can be evicted from physical RAM, since it can be reloaded at will).

Since sharing is on a per-page basis, this means that dynamically altering the call argument (the few bytes after the call opcode) should be avoided. Instead, the compiled code uses a Global Offsets Table (or several -- I simplify things a bit). Basically, the call jumps to a small piece of code which does the actual call, and is subject to modification by the dynamic linker. All such small wrappers, for a given object, are stored together in pages which the dynamic linker will modify; these pages are at a fixed offset from the code, so the argument to call is computed at static link time and needs not be modified from the source file. When the object is first loaded, all the wrappers point to a dynamic linker function which does the linking upon first invocation; that function modifies the wrapper itself to point to the resolved target, for subsequent invocations. The assembly-level juggling is intricate but works well.

Data accesses follow a similar pattern, but they don't have relative addressing. That is, a data access will use an absolute address. That address will be computed within a register, which will then be used for access. The x86 line of CPU can have the absolute address directly as part of the opcode; for RISC architectures, with fixed-size opcodes, the address will be loaded as two or three successive instructions.

In a non-PIE executable file, the target address of a data element is known to the static linker, who can hardcode it directly in the opcode which does the access. In a PIE executable, or in a DLL, this is not possible since the target address is not known before execution (it depends on other objects which will be loaded in RAM, and also on ASLR). Instead, the binary code must use the GOT again. The GOT address is dynamically computed into a base register. On 32-bit x86, the base register is conventionally %ebx and the following code is typical:

    call nextaddress
nextaddress:
    popl %ebx
    addl somefixedvalue, %ebx

The first call simply jumps to the next opcode (so the relative address here is just a zero); since this is a call, it pushes the return address (also that of the popl opcode) on the stack, and the popl extracts it. At that point, %ebx contains the address of popl, so a simple addition modifies that value to point to the start of the GOT. Data accesses can then be done relatively to %ebx.

So what is changed by compiling an executable file as PIE ? Actually not much. A "PIE executable" means making the main executable a DLL, and loading it and linking it just like any other DLL. This implies the following:

Function calls are unmodified.
Data accesses from code in the main executable, to data elements which also are in the main executable, incur some extra overhead. All other data accesses are unaltered.

The overhead from data accesses is due to the use of a conventional register to point at the GOT: one extra indirection, one register used for this functionality (this impacts register-starved architectures like 32-bit x86), and some extra code to recompute the pointer to the GOT.

However, data accesses are already somewhat "slow", when compared with accesses to local variables, so compiled code already caches such accesses when possible (the variable value is kept in a register and flushed only when needed; and even when flushed, the variable address is also kept in a register). This is made even more so by the fact that global variables are shared between threads, so most application code which uses such global data uses it only in a read-only way (when writes are performed, they are done under the protection of a mutex, and grabbing the mutex incurs a much bigger cost anyway). Most CPU-intensive code will work on registers and stack variables, and won't be impacted by making the code position-independent.

At most, compiling code as PIE will imply a size overhead of about 2% on typical code, with no measurable impact on code efficiency, so that's hardly a problem (I got that figure from discussing with people involved in the development of OpenBSD; the "+2%" was a problem for them in the very specific situation of trying to fit a barebone system on a boot floppy disc).

Non-C/C++ code may have trouble with PIE, though. When producing compiled code, the compiler must "know" whether it is for a DLL or for a static executable, to include the code chunks which find the GOT. There won't be many packages in a Linux OS which may incur issues, but Emacs would be a candidate for trouble, with its Lisp dump-and-reload feature.

Note that code in Python, Java, C#/.NET, Ruby... is completely out of scope of all this. PIE is for "traditional" code in C or C++.


Public Key Infrastructure: Sending data securely to CLIENT?

1. Handshake

It all starts first with a handshake. The client tells the server what version of SSL it supports and what cipher suites. The server answers with the information on which version of SSL and which cipher suite will be used.

2. Cerfiticate

The client now has to check if the server really is who he sais he is. This is done with the certificate. The client verifies the name of the holder, the domain, public key, signature and the date when it will expire. The check of these information is done by asking the certificate authorities if it is valid or not.

3. Key exchange

Now that everything is almost set up, the client generates a random symmetric key that will be used for encrypting the data sent back and forth between the client and the server. (note: both ways are encrypted!) The client then encrypts this symmetric key with the asymmetric public key of the server and sends this information to the server. Only the server can read this data, because it only can be decrypted using its private key. So now both parties have the symmetric key that will be used to encrypt and decrypt the data of the communication.

The reason why there is a symmetric key is because of performance. Using only the asymmetric public key of the server would be much to slow and is even bound on limitation of the size of the data. And as you pointed out, the server otherwise couldn't send encrypted data back to the client.

I hope this gives you a brief understanding in how SSL works.


The problem is that you sometimes refer to https resources by https://jlucina.com; for example one image is located at: https://jlucina.com/sites/default/files/pin.png

Now your web site is setup that https://jlucina.com 301 redirects to http://www.jlucina.com, so despite the https in the source the resource is sent unencrypted over the network, so you get the partially encrypted warning in firefox.  So if you try going to https://jlucina.com/sites/default/files/pin.png you end up at http://www.jlucina.com/sites/default/files/pin.png which is your mystery unencrypted media resource.

You can use curl to see the http response headers:

$ curl -I https://jlucina.com/sites/default/files/pin.png
HTTP/1.1 301 Moved Permanently
Date: Thu, 23 Aug 2012 10:15:05 GMT
Server: Apache
Location: http://www.jlucina.com/sites/default/files/pin.png
Cache-Control: max-age=1209600
Expires: Thu, 06 Sep 2012 10:15:05 GMT
Connection: close
Content-Type: text/html; charset=iso-8859-1

I got to the bottom of this by using a tool like firefox's web console, seeing what's sent over the network on port 80 (facebook.png, twitter.png, pin.png) and then going back to the page, seeing how/where they were referenced and eventually figuring out https://jlucina.com differed from other https links and used curl to check the headers of the request.


Submit W1 to various anti-virus vendors. Eventually after a few months, W1 will be removed from most computers by the anti-virus and you do not need W2.


What is one of the best ways to determine whether or not a user is
  abusing IPs?

There's no good way, and it probably shouldn't be your goal.

The fact that you've been "tracking actively-used IP addresses for each user" means that you already have a tracking mechanism better than IP addresses that you should use instead.

  As we've been tracking IPs, we notice that sometimes users hit a limit
  of 10 IPs but only the last quadrant of their IP changes. Does the
  pattern/style of IP change indicate the type of service they might be
  using to alter their IP? (Sometimes it's a combination of the third
  and fourth quadrant that changes.)

It suggests that they're staying in the same office, using the same coffeeshop, wandering around the same mall, connected to the same ISP but have changing addresses, or are using an anonymizing proxy provider (which one can do for legitimate reasons).  Nothing bad or unusual about any of that.

  How can you determine if a user has a dynamic IP in a web application?

If it changes, it's dynamic.

If it doesn't change, it might still be dynamic.

If it's static, it's not dynamic, but it still might change.

Client IP is not something you can reliably draw many conclusions about.  Use authentication, use cookies, use client certificates, but don't use IPs to track anything about the endpoint.


What should a secure passphrase look like?

The concern is perfectly valid for short passwords like a PIN for a payment card. If you generate a random four digit PIN, you have a 0.01% chance of generating “1234”, a 0.05% chance of generating “flush“ in format n & (n + 1) & (n + 2) & (n + 3)*, a 0.07% chance of generating “reverse flush” (n & (n - 1) & (n - 2) & (n - 3)*), a 0.1 % chance of generating a PIN that has all digits the same and so on. Maybe those probabilities are low, but they are still non-negligible and when you sum all of them (and ideally add some other undesired patterns), the likelihood of having one increases.

Adding some rules for PIN generation is a bit tricky, however. If you are too eager to reduce the PIN space, then the attackers also have a smaller set of potential PINs to try.

The longer the password is, the less this is a real threat. For a 6 character password (^[a-zZ-Z0-9]{6}$, uniformly distributed), generating passwords like “123456” is rather unlikely (but still somewhat plausible). When you generate a password using 128 bits of entropy, the probability that you will happen to generate an obvious password that crackers would guess is almost zero.

The same applies for passphrases, except that entropy estimation is harder for passphrases than for random passwords.

* The “&” operator is string concatenation.


How to make an outbound request to users to update their passwords?

Technical half: changing the password

The simple and secure way is a round-about, "You don't."

When a user logs in with their old password, display a notice saying they must reset their password. Generate an email with a reset token and send it to their email address. The email address token must be used because we no longer trust the password (and we hope that the email address is still under a users' control).

Human half: discussing a breach

If you're requesting users update their passwords, it may be because you're changing hashing algorithms. That really should happen behind the scenes, or involve reclaiming old accounts rather than leaving them dormant. It probably is because you've encountered a breach, though.

Breaches affect customers even if you don't hold any sensitive information because online presences are often linked (same username, email address, etc.) and because passwords are often re-used. If you've lost control of your password database, users may be at risk of having those passwords brute-forced and then used against accounts from other sites.

Regardless of your motivation, the technical method of changing passwords remains the same. If you've had a breach, though, disclosing that is important for your ethical duty to your users and sometimes for legal requirements depending on your jurisdiction. How the letter is written is a combination entirely of legal and subjective matters, but it should explain why users may need to be concerned about other accounts and why they need to reset their password on their next login.


Are there tracking methods for targeted ads from regular cell phone use, and how can one monitor that?

The tracking methods are not all located in your phone.  For example, Verizon has been adding their own custom header, X-UIDH, to cell phone HTTP requests that pass through their network; and are using this to track users across the web.  Because it's injected by servers in their network and not by your browser or phone, there is no phone-based firewall or software solution capable of stopping this.  And as Verizon strips it out before it's returned to your phone, you aren't even able to detect it without looking at the traffic that arrives on a web server.

If this concerns you, and you are a Verizon subscriber, your best defenses are to use encryption.  While HTTPS Everywhere may seem like a good idea, I wouldn't put it past a phone company like this to install a proxy certificate on your phone that would enable them to MitM your HTTPS traffic.  Instead, encrypt all your phone's traffic before it leaves your phone, either using a VPN or Tor.  And you may want to switch to WhatsApp if you want to keep them from listening to your voice.  Since it seems kind of foolish to buy phone service from a company that can't be trusted, if this is a problem for you you should probably shop around for a phone provider that isn't violating your privacy.

Of course, this merely shifts your security burden to a different entity, but at least you can shop around for one that is more aligned with your privacy interests.


Best way to securely send passwords from an application to a user operated server

You can use the Internet Protocol Security (IPSec). This way your LAN communications are both authenticated and encrypted for each IP packet of a communication session. It is not a problem whether your machines are running Windows or Linux based operating systems. Note that you can also use it in conjunction with Layer 2 Tunneling Protocol (L2TP) that interoperates perfectly with IPSec.


PHP | Security for allowing user uploads

When it comes to allowing user file uploads, you must be very careful. This is just a list of things to start with, off the top of my head:

Ensure that files cannot be executed by users

Set up your PHP in such a way that it will not consider using the PHP file extension in the folders where PHP files exist.
Make sure the permissions for the files are set correctly. If there's no need for uploaded files to have execute permissions, then why should they?

Preventing users from grabbing arbitrary files

Unless you really want them too, a user should not be able to enumerate all the files uploaded to your service. In fact, based on your description of the service there is no reason they should ever be able to download the file again.

Provide hard to guess unique ids in the file name. Many sites uses long, complex filenames for things as trivial as pictures in order to provide metadata, and prevent enumeration.
Make sure your that your system is configured to detect enumeration. A user should not be able to make thousands of incorrect guesses at the name of resource. You can do this through i.p tables, fail2ban, IDS, application, database. Depends on a lot of things and lots of ways to go.
If the users don't ever need to retrieve said file from your server, make sure that it is brought to a place where it cannot be accessed directly (like outside webroot.)
Consider hosting your files on a different server than other application parts (like the business logic and such.)

Ensuring that files do not cause issues directly for your system

You describe your service as a virus scanning service. What you are trying to do may be dangerous. It is not inconceivable that a virus might leverage the AV itself to escalate privilege.

Do some basic scanning to determine the validity of the file before sending to AV. Users should not be able to send severely mangled files which may crash the AV.
Check the headers.
Use programs like fileinfo.
Check against known file type information.
scan the file for obvious mangling/fuzzing attempts. For instance, a file filled with 10 thousand A characters might be testing your system.

Ensuring that the AV will not cause an issue

make absolutely sure you are using a trusted AV software which is fully patched and up to date.
Ensure that the AV software has the proper rights, and does not expose unnecessary ports.

Isolating the system in case of breach

Again, insure that the system holding the files has minimal rights.
Try using a container/jail/sandbox of some sort to limit the effectiveness of an exploit attempt.