How sensitive is information on a system's architecture? How much easier would it be to break into a system if you knew the following information?

Processor architecture / family
Operating system
Libraries used
Application programming language
Standardised protocols used

I'd like to know how much easier and which components are most sensitive in this regard (subjective answers OK). Assume that, other than this information, reasonable effort was made to make the system secure, e.g. secure protocols and keys would be used where appropriate.

This information is not sensitive.
An attacker would gain very little by knowing these facts beforehand. Many of them are either not relevant to their campaign, or trivial to detect remotely, even if the configuration is not published. In order to answer adequately, you may want to elaborate on what you mean by "break in". Is the attacker attempting to bypass authorization remotely? Do they have a local process running on the system and are attempting to elevate privileges? Are they trying to root a commercial embedded system that they have purchased and have physical access to? Hiding this information may slow down someone who is trying to jailbreak a commercial system for a short amount of time by forcing them to spend time reverse engineering it, but it will do nothing against an attacker with a local shell trying to get root.
There is only one situation where hiding certain information is beneficial, and that is when an attacker is attempting mass-exploitation of a remote vulnerability. Having your application withhold its exact version can decrease the chance that an army of bots scanning the entire internet will attempt to exploit you. This will not protect against anyone who is looking to exploit you specifically, however.
Details you are trying to hide

Processor family

The processor family itself tends not to matter. The overwhelming majority of exploits, of all kinds, will work equally well on Skylake as on Kabylake. If you're talking about processor architectures, then it starts to matter, as MIPS shellcode will not work on an ARM system, and vice versa. However, this is not something that should be obscured, as the majority of servers and systems in general are running x86, mobile systems tend to run ARM, and embedded systems often run MIPS.

Operating system

Whether or not the operating system even needs to be known depends on what is being exploited. If a web app is being attacked, the operating system may not even be relevant. A SQLi vulnerability in a popular web platform will work equally well on Windows, Linux, FreeBSD, Solaris, or any other operating system that can run the vulnerable application. If the attacker is trying to attack the system itself to elevate privileges, it may be necessary to know the operating system. This information can be obtained remotely through a technique known as OS detection, or OS fingerprinting.

Libraries used

There are some libraries that will generally always be used. You will practically never find something that does not link against libc. A program doing math will likely use libm. A program that accepts user input via CLI will likely use libreadline. There are not many exceptions. If an attacker is trying to exploit a program, they only need to know the libraries in use if they are exploiting a particular vulnerability in the library. It's easy to check which libraries a program needs, as the list is encoded into the executable itself. Various scripts like ldd can gather this information from an executable.

Application programming language

The programming language for a vulnerable program may matter, depending on the type of exploit that is being used. A language like PHP which does its own memory management (is memory-safe) tells you that you will not need to attempt a stack overflow, as memory is managed. A C program on the other hand may be vulnerable to such a bug, as it is lower level. Knowing the language itself is neither necessary, nor sufficient for exploitation. The overlap in knowledge between a person who knows enough about a program to exploit it, and a person who does not know the language it uses, is zero.

Standardised protocols used

Some protocols are more vulnerable than others. DCCP for example has a history of nasty vulnerabilities. Rather than attempting to hide the protocols you are using, it would be far better to disable the unnecessary ones, as an attacker can simply attempt a connection with said protocol to see if it is supported. If the connection fails, it is either unsupported, or the port is closed. Either way, attacking the protocol itself will not be possible if it is not open and supported.
Types of attackers
There are different types of attackers. For this answer, let's split up the types of attackers into local, remote, and physical, and see what position they are in to gather the information they need.
Local attacker
A local attacker is running a process on your system. They want to elevate their privileges, or move laterally to other users. They may or may not be sandboxed. A local attacker is one of the most dangerous, as they have access to any information the operating system willingly gives out.

Processor family - Unnecessary, but can be retrieved in /proc/cpuinfo.
Operating system - If they are running locally, they most likely already know the operating system.
Libraries - If they have access to the executable, then can run ldd or readelf on it.
Language - Checking the libraries in use gives away the runtime, revealing the language.
Protocols - Using the socket() syscall can allow testing if a given protocol is supported.

Remote attacker
A remote attacker is trying to compromise a server. Their only interaction with the target is over the network, subject to any firewall rules that may be in play. They want to gain unauthorized access to the system by exploiting vulnerabilities in remotely running services.

Processor family - Unnecessary to know, but can probably be guessed.
Operating system - Many tools can remotely reveal the operating system being used.
Libraries - Very few remote exploits need to know the specific libraries being used.
Language - If they know a service well enough to attack it, they know the language.
Protocols - An attacker can attempt to connect using a particular protocol. If it fails, it is either not supported or firewalled off. The attacker does not care about the distinction.

Physical attacker
A physical attacker has your device in their hands. They may be trying to reverse engineer it and jailbreak it to expand its functionality or access secrets it is storing. They can open the device, look at the labels on the components, dump firmware, and possibly even attach the CPU to a debugger. This is the most powerful class of attacks. There is generally no way to prevent a physical attacker from gaining detailed information about your system, given enough time.

Processor family - This can be determined by reading the CPU's datasheet.
Operating system, libraries, language, and protocols - Dumping the firmware reveals this.

Summary
In general, this information is either easy to find out, not necessary to know, or difficult to hide. There are far better ways to improve your security. Now, what you should do, rather than hiding the following:

Processor family - Make sure you are using a modern processor with valuable security features like NX, SMEP, and RDRAND. A good operating system can take advantage of processor security features to enhance your security. CISC systems are easier to exploit using ROP. Systems with out-of-order and speculative execution can be vulnerable to side-channel attacks.
Operating system - Use a secure operating system, kept up to date and configured securely. OpenBSD is more secure than an old Windows server. Linux with grsecurity is more secure than a poorly maintained CentOS system. A custom kernel configuration or whitelisted modules can allow you to disable unnecessary drivers and other risky features.
Libraries used - Ensure all your libraries are kept up to date. If a vulnerability is discovered in a library, update it and restart any application that is running and which links against it.
Application programming language - When possible, use a language that is memory-safe. It is harder to get things wrong when writing in python than it is when writing in C.
Standardised protocols used - Only enable the protocols you need. Unnecessary protocols may be exploitable locally or remotely. If you have whitelisted your protocols to only the core basics necessary to run adequately, exploiting you through a networking vulnerability will be much harder.

While there is no reason to reveal all this information (assuming you are not expecting collaboration, where revealing information can help people point out bugs for you to fix), some of the details you mention are either so irrelevant or so easy to detect that you would have to go to excessive lengths to hide that information. Simply disabling version information is one thing. Wasting effort trying to prevent someone from knowing if you are on an x86 system or a SPARC system is just unnecessary.
Some resources you might be interested in:

What is the best way to explain (a non-technical person) the risk of leaking version information?
Is it safe to reveal information about the OS and the software you use?
Hiding version - valuable or just security by obscurity?
The valid role of obscurity
Is displaying what server I am running on the error pages a security risk?
OWASP - Testing for Web Application Fingerprint


Are social media websites a security risk? If yes, how do we go about making them safer for users? Generally speaking, I'm looking at a business environment. I know that Facebook Ads are not vetted and can contain malware, also users can share files on some social media sites. But what else is there? And are there any practical solutions to these problems?

As you said, the main threats on Facebook are the ads and malicious links/files users can share between each other. In terms of Ads, you can use an ad-blocker such as uBlock Origin or AdBlock, which as the name suggest will remove any side-bar ads.

In terms of not clicking malicious/suspicious links, well, that's down to the user, as long as they are well informed then there's not too much else you can do - it's assumed they don't open spam e-mails and click those links, so perhaps explain to your users that they should treat suspicious Facebook links in the same manner.

As already mentioned, the real, and perhaps most dangerous threat is one that you cannot prevent or guard your users against, which is social engineering. It helps to keep your private life private but unfortunately not everyone considers that, which makes Facebook a real goldmine for anyone with time on their hands and a malicious intent.


Is this enough to tackle script / malicious code insertion in GET, POST requests? I've got legacy PHP code which attempts to prevent script/SQL injection with the following:

if (!empty($_POST)) {
    reset($_POST);
    while (list($k,$v)=each($_POST)) {
        if(!is_array($_POST{$k}))
        {
            $val=str_replace("&amp;","&",htmlentities($v,ENT_QUOTES));
            $$k=$val;
            //$_POST{$k}=$val;

            if (!get_magic_quotes_gpc())
            $_POST{$k}=$val;
            else
            $_POST{$k}=stripslashes($val);

        }
    }
}

The same is exactly replicated for $_GET as well.

Is this enough to prevent script/SQL injection?

No. It's blacklist-based, it tries to take care of specific tricks involving html entities.  It doesn't even require magic_quotes, and magic_quotes has been deprecated as inadequate.  Chris Shiflett is just one of many who've written a blog post explaining how vulnerable that is; it won't even stop modern automated script-kiddie attacks.

Use prepared statements in the database, and you'll be most of the way there--although even prepared statements aren't foolproof.


How to trace a (mobile) phone? Even since growing up, I've watched films in which the "bad guy" is repeatedly tracked down when they call the police or FBI or police force de jour.  They always have "about 30 seconds".  Regardless of whether those specific realizations are accurate or not, I've never understood what is going on technically when a phone is traced.

This question has three related parts:

What are the technical aspects to tracing a phone call; is it more difficult for mobile phone?  Is it more difficult if the phone is on, but not actively being used to call?
Why are the tools necessary to trace phone calls not available to the general-public?  We have traceroute to find routing information for IPs -- why not phones?  Is it a question of specialized equipment, access to telecom systems, etc. or more social?
How does one prevent a (mobile) phone from being traced?

What are the technical aspects to tracing a phone call; is it more difficult for mobile phone?

In the old days, signaling was inline, hence the 2600hz hack. Calls were setup as one switch talked to another, then another, and so on until a circuit was established end-to-end. In the modern age, everything is out-of-band over SS7 and every switch is lined up at the same time. The calling station is identified at the start and no tracing is really necessary.

Mobile phones do take more effort because a mobile number isn't attached to a given switch. Thus, while the far end knows what the number is, where it is involves extra technology. The cellular phone company can identify what towers the phone is associated with and thus instantly know the region it is in. Further narrowing can be done based on signal strength comparisons, which of the tower's directional antennas are holding the signal, and GPS chips in phones.

  Is it more difficult if the phone is on, but not actively being used to call?

Only a custom phone would act in a way where it didn't respond to the tower asking a question, so generally no.

  Why are the tools necessary to trace phone calls not available to the general public? We have traceroute to find routing information for IPs -- why not phones? Is it a question of specialized equipment, access to telecomm systems, etc. or more social?

Social legacy and equipment access. The Internet doesn't have a separate signaling band and is based on the idea of independent operators controlling where their traffic goes. The phone company is based on the legacy of one company running the show. Switch access in the phone world is internal only to the phone company or whoever they want to specifically include. The Internet, on the other hand, doesn't really have a way of considering nodes special since everything is in the same band.

  How does one prevent a (mobile) phone from being traced?

Nothing will save you from being traced down to the tower you're using, but you can really screw around with the triangulation metrics by using a directional antenna and some weak false associations or intermediary transmission layer such a radio that links you to your phone. In that case, finding your phone would leave the person chasing you still lacking a physical connection and having to trace something else. Done right, you can turn the default, "Within 100 feet," into, "Somewhere in this 20 square mile cone." That is a big time, knowledge, and equipment cost commitment, though.

You may also find some success in delaying tracing by using intermediate PBX systems to mask the actual caller. If you have dial-in access to a company's PBX, the trace will stop there and somebody will have to look at logs of associated calls into the system to try and correlate the responsible line. Nest a few of those and you may buy some time. You'll probably still eventually be traced no matter how short the call was, but it will no longer be instant.


distributing SSL certificates? I'm only familiar with SSL certificates in a simple-use case: I've installed them to websites, Windows servers, and a few Linux servers.

I'm now faced with the task of securing every possible device in our international network with SSL certificates. I've purchased a wildcard *.mydomain.com certificate from Comodo so that I can use the same certificate everywhere, but I'm still faced with the mountainous task of installing certificates to many Windows servers, apache servers, Linux servers of various flavors, proprietary OS's, desktops, and even printers.

What is most daunting about this task is that I will need to do it again and again - every time the SSL certificate expires. I know I can purchase a 5-year certificate, but even still, it is a hassle I'd rather not have to repeat.

Is it possible to have one system (like a Windows domain server) act as a certificate server and then just load every other device with a certificate that "points" to the certificate server for validation? My idea is that I would only have to update the certificate in one central location, and then all the other devices pointed to that server would automatically be current. I've already noted that there are concepts like "Intermediate CAs", "Certificate Chains" and "Local CA Authorities", but I'm not sure if it is possible to leverage those concepts into helping me distribute a certificate from a big-name CA down the network...

In order to perform this task, you typically rely not on a single cert but on an internal certificate authority.

You first setup your own , off-line root CA and then immediately setup at least one (usually more) intermediate certificate authority with keys signed by your private root (if you're using a windows AD infrastructure, these ICAs can be setup using windows certificate services server and then integrated within you AD).

Once properly deployed (which isn't a trivial task), then you can generate and renew certificates for your servers very easily.

The weak point of this strategy is that it typically only works internally: external systems will not recognize your root as valid. A typical method of solving this is to use reverse proxy servers placed at your perimeter that will offer to external clients a certificate signed by a public root and connect to the internal systems. Since these proxies should have your private root installed, they will be able to validate your connections.

Note that this is a very high level description of the strategy: implementing it securely and globally is not easy and should be done extremely carefully.


What is a DoS Attack and how does it differ from a DDoS attack? Can someone explain to me the concept of DoS attacks for web applications? Also, what is the distinction between DoS and Distributed DoS (i.e. DDoS) attacks? Wikipedia says:

  In computing, a denial-of-service attack (DoS attack) or distributed
  denial-of-service attack (DDoS attack) is an attempt to make a machine
  or network resource unavailable to its intended users

which means they are the two different names for the same attack.

But then again, I found out this article from Computer Crime Research centre website titled Network security: DoS vs DDoS attacks. So I am assuming that these are two different types of attacks.

A denial-of-service attack is a type of attack that causes legitimate users to be unable to use the service. These come in a few different categories:

Resource exhaustion (e.g. consuming all network bandwidth, or server CPU time)
Limitation exploitation (e.g. locking a user out of their account by repeatedly attempting to log into it with invalid credentials)
Process disruption (e.g. crashing a process that serves user requests, via a bug in the software)
Data corruption (e.g. altering all user types to an invalid type, making it impossible for them to log in)
Physical disruption (e.g. pulling out the power cable on a server) - thanks to Henning for this one!

The most common type on webapps is a resource exhaustion, which is what most people tend to refer to as a DoS. These are caused by an attacker sending a large number of requests to the server, in order to exhaust one or more resources:

Network bandwidth may be entirely consumed by the attack, preventing legitimate user traffic from reaching the server.
Each request uses some CPU time, so a large number of requests may cause the CPU to spend all of its time dealing with attacker requests, instead of legitimate requests. Attackers can send expensive requests (e.g. full-text searches, SSL connections, etc.) to the server to increase the impact. There are also cases where vulnerabilities in the server software allow the attacker to craft special requests that eat a lot of CPU time.
A small amount of RAM is used for storing the connection state, which might allow for physical memory exhaustion if enough connections can be made. However, database queries can be very memory intensive, in terms of memory usage and memory bandwidth. If an attacker picks his queries well, he might be able to entirely exhaust the physical memory of the system.
Logs, database tables, etc. are stored on disk. Sending a huge number of queries over a period of time may exhaust the disk space on the server, causing it to crash.

Note that the requests don't need to be HTTP - they could be DNS, HTTPS, SSH, FTP, SMTP, POP, IMAP, SMB, etc. Any situation where a service is listening for incoming packets is a potential way to achieve a DoS.

There are two primary ways to achieve basic application-independant network DoS attacks: TCP SYN floods and UDP flood.

The TCP protocol involves a three-way handshake. First, a client sends a SYN (synchronise) request, to which the server responds with a SYN-ACK (synchronise acknowledged), which the client then finally responds to with an ACK (acknowledge). However, if a client sends a SYN and does not respond to the SYN-ACK, the server is left with a half-open connection. This consumes a small amount of memory within the operating system, and eats a few CPU cycles. Eventually the connection is dropped, but a flood of SYN packets can be enough to cause serious performance issues on the target. There are a number of ways to mitigate this threat, and the most notable is SYN cookies, which allow the server to send back a response without storing the SYN state.

The UDP protocol doesn't involve any form of handshake. Packets are simply sent between hosts, with no state or connection. This means that an attacker can send a large number of UDP packets to the server, consuming their bandwidth. This requires that the total bandwidth of the client exceeds that of the server. Since the client doesn't need any response, it can spoof the source IP address, making mitigation harder. These types of attack can be harder to block, and often require intervention by the service provider.

The problem for attackers is that servers are designed to cope with a large number of concurrent users, and small denial of service attacks. Sending a huge number of packets from their home network or a rented server is unlikely to cause a significant reduction in availability or response speed of their target. In order to make the attack more effective, they use a distributed denial of service (DDoS) attack. This involves using a number of computers on different networks to flood the site with requests. Often the attacker will infect other computers with malware, to form a botnet, which is then used to perform DoS attacks. The difference is that a DDoS allows traffic to flow from legitimate (but compromised) source IPs, increasing the effectiveness of the attack and making it harder to block.


Is Webroot's Business Endpoint Security up to snuff for mobile workforce? I'm in a small software company and getting ready to begin supporting 7 remote sales guys out on the road.  They all have recent ultrabooks and most of the tools they will be using are in in the "cloud" (SaaS tools such as Salesforce, Box.com, Office365 etc.).  They all currently have Microsoft Security Essentials installed, but I'd like to be able to centrally manage things including updates and alerts.

I'm looking at Webroot's SecureAnywhere Business Endpoint Protection since it is centrally managed and "cloud-based" meaning that I don't have to manage the server that manages the clients.

Webroot claims to have a tiny footprint, but I'm wondering what their reputation is for effectiveness.

An independent review of various AV products by AV Comparitives put it in 20th position out of 22 tested - hardly a glowing review. You can get the PDF of the report for free.

It scored 1/3 for detection rates, 0/3 for proactive detection, 3/3 for suite performance, 3/3 for AV performance, and 3/3 for anti-phishing[pg.3]. However, this rating is only for scanning when internet access is available, since it uses cloud-based scanning. If no internet access is available, the detection rate drops significantly and misleading alerts are logged about various networking operations being monitored[pg.177]. If they're out in the field and might not always have internet access, I'd probably avoid this solution.

Possible alternatives in terms of performance are ESET and avast!, both of which have a reasonably low footprint. If you're looking for maximum protection, you may want to look at BitDefender or Kaspersky. If you're hoping to heavily leverage cloud-based scanning, Panda Cloud AV might be what you want, though it does hog resources a little.


OpenPGP keyserver URLs: what are typical or meaningful use-cases? i'm getting re-acquainted with OpenPGP and noticed that GnuPG allows me to store a "preferred keyserver" URL in my keys:

reuben@localhost:~$ gpg2 --edit-key 'Reuben NP Garrett <my-special-email@example.com>'
gpg> help
..
keyserver   set the preferred keyserver URL for the selected user IDs

this seems to influence GPG's 'refresh-keys' operation, since when i tried setting this value to http://pgp.mit.edu/ (where i'd previously published my keys), GPG complained of "no key data found for http://pgp.mit.edu/". however, when the keyserver URL was set to an unreachable value (https://pgp.mit.edu/), GPG instead complained that it "couldn't connect to host" and failed over to keys.gnupg.net (as a built-in server, i suspect).

is the "preferred keyserver" URL supposed to directly target my key, e.g. http://pgp.mit.edu/pks/lookup?op=vindex&search=0x0B17E17AADF01139? or what is a "correct" (or useful/meaningful) way to set this property?

The Option

This option allows you to setup the preferred key server others should (but not must) use when refreshing your key. This could be your own, or the one your institution provides. A preferred key server can reduce the synchronization latency between OpenPGP participants.

Key Exchange Protocols

You must not enter the http URL of the key server. GnuPG uses another protocol for key exchange, namely hkp. For pgp.mit.edu use hkp://pgp.mit.edu.

There is a post on security.pgp-basics describing all the available protocols:

ldap (might be important in some enterprise scenarios)
hkp (the de-facto standard for all key server operations ourdays)
http
finger
mailto (had broad usage in earlier days, especially for exchanging information between key servers)

SKS Key Server Pool

Even better, use the SKS key server pool MIT is participating in: hkp://pool.sks-keyservers.net. Most key servers (but http://wwwkeys.pgp.net) are well-connected among each other and synchronize very fast, so selecting a distinct key server isn't very important. Using the SKS key server pool is usually recommended, as it contains all the relevant key servers and increases availability over using a dedicated key server.


How many rounds of hashing is enough for a password manager? I'm currently writing my own little password manager that stores the key in a SHA256 hash, with salt. I create the hash by doing the following:

def sha256_rounds(raw, rounds=100001):
    obj = hashlib.sha256()
    for _ in xrange(rounds):
        obj.update(raw)
        raw = obj.digest()
    return obj.digest()

After it is created it is stored with the following:

    key = base64.urlsafe_b64encode(provided_key)
    length = len(key)
    with open(key_file, "a+") as key_:
        front_salt, back_salt = os.urandom(16), os.urandom(16)
        key_.write("{}{}{}:{}".format(front_salt, key, back_salt, length))

The questions/concerns I have are:

Is this an acceptable way to store a hashed key?
Should I use more iterations?
Is my salting technique sufficient? Or should I use a different salting technique?

If this is not an acceptable take on storing a hashed password/key, what other steps can I take to make this more secure?

UPDATE:

I took a lot of your guy's advice, and if you would like to see the outcome, so far, of my little password manager you can find it here. Everyone's advice is much appreciated and I will continue to strive to make this as excellent as possible. (if that link doesn't work use this one https://github.com/Ekultek/letmein)

I'm currently writing my own little password manager

That's your first mistake. Something this complex has many subtle pitfalls that even experts sometimes fall into, without plenty of experience in this area you don't have a chance making something even close to secure.

  stores the key in an SHA256 hash

Uh oh...

This doesn't necessarily indicate you're doing something wrong, but I have strong doubts that you're going to do it right. I assume you're talking about a master password being hashed here? The master password should be turned into a key using a KDF like PBKDF2, bcrypt, or Argon2, then this key is used to encrypt the stored passwords.

If you want to have a way to verify that the password is correct, storing a hash of the key should be fine, but you MUST NOT store the key itself...if you store the key anyone who gets access to your storage has everything they need to decrypt all the passwords!

If you aren't talking about hashing a master password and you do mean an actual randomly generated key then I have no idea what you're trying to accomplish here, but you shouldn't be using a slow KDF with a large number of iterations.

Alternatively you could be hashing the master password twice, once to store as a hash to later verify that the password the user enters is correct, and again to use as a key for encryption. Depending on how this is done it could range from a design flaw to completely giving away the key.

Edit: After seeing the full code it seems to be a fourth option: you store a hash of the password to later check if the entered password is correct, then you hash this hash to use as the key, which is nearly as bad as just storing the key itself.

  I create the hash by doing the following:

def sha256_rounds(raw, rounds=100001):
    obj = hashlib.sha256()
    for _ in xrange(rounds):
        obj.update(raw)
        raw = obj.digest()
    return obj.digest()

It's not really clear what raw is here, but I'm assuming it's the password. What you're doing is an unsalted hash using SHA256. Don't try to create your own KDF!

  After it is created it is stored with the following:

key = base64.urlsafe_b64encode(provided_key)
length = len(key)
with open(key_file, "a+") as key_:
    front_salt, back_salt = os.urandom(16), os.urandom(16)
    key_.write("{}{}{}:{}".format(front_salt, key, back_salt, length))

So, you're creating the key by hashing the password, then adding a random salt to the front and back? Not only is concatenating 2 different salts to the front and back non-standard, it's not accomplishing anything here because it's done after the KDF has already finished! You're just adding in some random values for the sake of having them there.

To show just how bad this is (as of commit 609fdb5ce976c7e5aa1832670505da60012b73bc), all it takes to dump all stored passwords without requiring any master password is this:

from encryption.aes_encryption import AESCipher
from lib.settings import store_key, MAIN_DIR, DATABASE_FILE, display_formatted_list_output
from sql.sql import create_connection, select_all_data

conn, cursor = create_connection(DATABASE_FILE)
display_formatted_list_output(select_all_data(cursor, "encrypted_data"), store_key(MAIN_DIR))

While it may be a good learning experience to try creating a password manager, please please don't ever use it for anything remotely important. As @Xenos suggests, it doesn't seem like you have enough experience that creating your own password manager would really be beneficial anyway, it would likely be a better learning opportunity to take a look at an existing open source password manager.


Is it possible to reset digital camera shutter counter? This is such an important counter because a lot of people use it as the only way to tell if a camera is new or second hand. I have searched through google but it looks like no one can prove this can be reset. Is it possible?

In general? No. For some specific models? Yes.

for some Canon models supported by CHDK, you can sometimes gain write access to internal memory counters.
some other models have two batteries (and a capacitor) and pulling both batteries out, waiting long enough to drain the feed capacitor, will zero all counters.
sometimes re-flashing the firmware will do the trick.

For this reason, if you buy a camera, do not rely on the frame counter but request a receipt or, if possible, verify the camera serial number on the appropriate site (sometimes you can ask a service centre. High-end cameras often have a device history record so that you can know e.g. that your "almost new" camera has had half its circuitry replaced three years ago. The data isn't online, but the service people can access it).

And if you sell a camera...

A: if you sell to some dummy, he won't check anything and you'll be able to sell him a used camera as new. But you would have been able to do so even without the hack, which was therefore useless.
B: if you sell to a non-dummy, he will check the frame counter, notice that it doesn't match the model age / dirt / scuff marks / gear smoothness / LCD luminosity / whatever, and correctly deduce that you're trying to pull a fast one. And you'll probably have lost the sale and your credibility; the hack in this case has been harmful.

The frame counter reset trick is likely to be worthwhile only on a very narrow range of buyer gullibility, and you'll have to balance the likelihood of pegging someone in that range against the likelihood of meeting someone in the wrong range, and the risk of misjudging where the mark actually stands.


What is stopping me from replaying an SSL certificate? Say I have the SSL certificate for google.com. I intercept it, edit the certificate with my own domain name and public key and use it to intercept all traffic to google.com. What mechanisms exist in the SSL certificate to prevent me from doing so?

When a CA signs a certificate they encrypt a hash which includes the host name of the certificate target using their private key. When the client receives the certificate they decrypt the hash using the public key for the CA (which is baked into the client) and check that it matches the hash calculated by the client. If the hashes don't match then validation fails and the connection should be aborted.

If you modify the certificate to change the host name then the hashes won't match
If you try and sign the certificate again (ie. replace the hash with your own) then the client won't trust it because it wasn't signed by one of their trusted CAs.
If you try and present a legitimately signed certificate for another domain then obviously the validation will also fail because the domain doesn't match.

Of course the above assumes the client validates certificates correctly, which is not always the case.


ECDSA ciphers and forward secrecy question about key exchange I have heard that with forward secrecy that the ECDSA ciphers generate different keys for "each session" because they are not dependent on the private key of the server. My question is how is "each session" defined? Does this different key approach mean it happens with each consecutive/different SSL connection to say the same server or does it happen within the existing SSL connection as server side SSL re-negotiation request happen?

Forward Secrecy

  The key used to protect transmission of data must not be used to derive any additional keys, and if the key used to protect transmission of data is derived from some other keying material, then that material must not be used to derive any more keys. In this way, compromise of a single key permits access only to data protected by that single key.

Perfect Forward Secrecy (PFS)

PFS holds true above, but satisfies the two properties below:

Generates random public keys per session for the purposes of key agreement
Does not use any sort of deterministic algorithm in doing so

Addressing your questions in SSL/TLS

  How is "each session" defined?

Ephemeral Diffie Hellman is used for PFS.  Using Ephemeral Diffie Hellman (DHE/ECDHE) forces each session to renegotiate its DH parameter every time a single SSL session closes.  So "each session" quite literally means as soon as the session ends the keys are destroyed.  No session IDs are stored by the server, so new keys are forced each time.

  Does this different key approach mean it happens with each
  consecutive/different SSL connection to say the same server or does it
  happen within the existing SSL connection as server side SSL
  re-negotiation request happen?

Doesn't matter if its the same server, or a server side re-negotiation the server shouldn't have cached session keys.  So new DH parameters are needed with *DHE cipher suites.  Now this is how the theory works.  Configuration is kind of a different story.  Some servers might have to disable session resumption to ensure this occurs.

RFC5246: TLS 1.2 Standard

  Implementations SHOULD generate a new X for each handshake when using
  DHE cipher suites.

A related question and answer.


does switching to linux remove existing computer virus if you change from a malware/spyware infected windows setup to a linux setup will infections migrate to linux if they were on the computer? (when you are hacked/infected is it the op system that is infected or the hard drive?

Some infections actually target your firmware (e.g. BIOS) which makes them difficult to remove or avoid.

But typically, yes. The virus is obviously still there where you left it on your Windows drive or partition. The files don't get removed unless you delete them.

But if you're running Linux, then none of your windows software will execute, which includes any malware.


Is hiding my Java desktop app inside a VM the best way to protect my Java source code? I need to distribute a Java desktop app to the user. I am looking at different ways to protect my source code from reverse engineering.

One method is to distribute a Virtual Machine (says Linux) containing the app running inside that VM, and make the root user of that having a password of e.g. 50 characters. The drawback is that the download size of my app is too big (some Gigas). And the next question is: can an attacker read my Java code from inside a VDI disk image ?

Another method is Ahead of Time (AOT) compiling to native. ExcelsiorJet seems to be the best tool for that, however that is not free. Obfuscating the source code is NOT enough, since the ones wanting to read your source code are the ones that mainly want to care about the information flow and data structure. This excellent article explains more about AOT and obfuscating. Now the question is: by using ExcelsiorJet to compile to native, is my native code relatively safe from reverse engineering ?

Still another way: to e.g. use C++ to write the most security critical code, compile it to real native, and expose my unimportant Java source. But this means I'll need to maintain both parts as well.

This question is bordering on product recommendation request / opinion, but I'll try to answer the parts that are on-topic.

First off, good reverse-engineers are good. With enough skill and time, java source, java bytecode, c++ source, and native assembly are all equivalent in terms of showing an attacker how your software works.
Building on @Zymus's comment, you're starting with conflicting requirements, you want to:

Give out your source code to people / machines that you don't trust, but
You don't want it to be reverse-engineerable.

If the computer they are sitting at is able to understand and run your code, then (with enough effort) so can the human. Full Stop.
When your starting point is "I want to give them my code, but I don't want to give them my code", I'm not surprised that you can't find a solution.

Directly answering your questions:

can an attacker read my Java code from inside a VDI disk image ?

Well, can the computer read (and run) the Java code from inside a VDI disk image? If so, so can the attacker.

Obfuscating the source code is NOT enough,

Okay, we're back to the conflicting requirements here; obfuscation is the act of making code that can still be run by a machine, but is hard for a human to understand. You say that's not good enough: you want to allow the attacker to run your code, but not read your code. That doesn't make sense.

is my native code relatively safe from reverse engineering ?
Still another way: to e.g. use C++ to write the most security critical code, compile it to real native, and expose my unimportant Java source.

Why do you assume that native code is harder to reverse-engineer than Java? Sure, there's more learning-curve to reverse-engineering assembly with tools like IDA Pro compared to reverse-engineering java with jad, but for a skilled reverse-engineer, the effort is very similar.

I like @Zymus' suggestion: if there are bits of code that you don't want the attacker to have, then don't give it to them; run it on a server and provide an API that only exposes the (less sensitive) input and output.


Is union based mysql injection able to read files outside database? Can files outside database which are not part of any tables in database be read via union based SQL injection? For eg
http://xyz.com/fetch?id=3
Consider id parameter is used at server side by cursor library to execute mysql query and no sanitisation is being done. Would something  like 3' union select '../../x.py' -- be able to give attacker x.py file which is not part of database?
For better reference to the problem (Flag 0): https://dev.to/caffiendkitten/hacker101-ctf-photo-gallery-4foi

SQL Injection can lead to Remote Code Execution in some scenarios. As you can see in this article, it is possible to read files from the Operating System, that are "outside the database".
Tools like sqlmap can help an attacker spawn reverse shells while performing a similar attack. Once an attacker has a shell, depending on the permissions of the user and if privilege escalation is possible, one can potentially take over a server.


Why would someone upload many iptables files during a security breach and are they a cause for concern? My workplace had multiple unauthorized access security failures over the last month. Since then, most computers have been scrubbed and user accounts purged. Data was recovered from offsite backups and the holes have apparently been plugged.

I am not IT and am not entirely familiar with what happened but since the entire security team was fired, the rumours are that it was a simple SQL injection attack. I am not clear on how much access they got. Our systems are a mix of Windows 7/RHEL 6.7/BOSS 6.0

Now after restore, I find that several hundred iptables files have been added to my user storage. They were added last month during the breach and IT told me they are not a cause for concern and won't do any harm. Also, I have never accessed any personal sites from those machines and all passwords and biometrics have been reset.

Here is the contents of just one of the files: http://pastebin.com/DVXnQmV0

My question is why would someone do this and should I be worried?

They obviously changed the rules to stop the hackers

Chain DENYIN  sole purpose is a blacklist of ip addresses.
Obviously, this list was derived from the log files as the sources of the attack.

Chain DENYOUT
Clearly is meant to log and drop outbound connections to the attacking list of IP addresses.  Just in case they are still in the system.

Chain INVALID
Is for packets that shouldn't occur on your network.

The rules look good, but as you said this is only part of your rules.  A hacker would not put rules in place to block themselves as that is self defeating.

Whoever wrote these rules knows something about security.  However, they should be using ipset in combination with IP tables for efficiency as excessive iptables rules use extra CPU cycles.  However, they were smart enough to divide the traffic into chains to at least make a bit easier on themselves.

Yet with an INPUT policy of drop, and making the last rule in INPUT drop just incase many of the other drops are un-necessary.  Except the last 3 log lines ALL of LOGDROPIN is redundant(538-555).

The fact that there are no subnets like (/30) or whatever would make it easy for a hacker to +1 their IP address and possible break in again.  Some IP you may not be able to subnet mask, but many of them you can.  If it turns out they used an amazon,google,microsoft cloud server, you can't block all of amazon,google,microsoft it doesn't make sense.

I am not auditing ALL your rules because I am not getting paid, however I have given you some good general info.  Don't post all of your rules, for me anyway, I am not doing a free audit of your whole system.


What are the hardwares used to protect against a DDoS attack on Network layer What hardware is used to prevent a DDoS attack on a network layer?

This question is for my project which I am doing. I have a game server and I need to simulate an attack - an SYN flood. So what hardware should I use to prevent it.

My assumption is that to place a IDS after a firewall so that it will detect unwanted traffic and filter it out. Also IP filtering method can be used for example bogon filtering.

Please let me know if these assumptions are correct, and if you have more info.

There is no way to prevent a distributed denial of service using a single appliance. The problem with a denial of service is that once the traffic reaches you it's too late.

The only way to mitigate the risk of a DDoS is to use DDoS mitigation services offered by companies like Rackspace,  Akamai  or Cloudfare. They actually scrub the traffic and check it's origin before it reaches you preventing illegitimate traffic from reaching your server. To successfully deploy such a service you need multiple datacenters across different countries to be able to check the legitimacy of the originating traffic using BGP.

This is why a single appliance at the entry point of your network doesn't suffice.


Why wireshark source ip tab lists other ip as well I was trying to capture some packets using Wireshark. I could find a lots of ip in the source address tab. Which ip do they represent. Which all packets are visible to wireshark when I run it in my system?

The source-address tab represents the address the packet claims it is coming from. Be adviced that this can be easily spoofed so it may in fact not be the actual sender of the packet.

In your case it may not be trivial to know who all the IP addresses are. However if they are not RFC1918 (private IP addresses) you can run them through a geoip service to learn more about the addresses coming to you.

If they are in fact RFC1918 addresses I would take a closer look at your network to find out who the machines are. In some cases a reverse DNS lookup may help you in identifying the machines.

Geoip using netcat:

ip.txt format:

begin
verbose
<ip address>
<ip address>
end

Build your file and do the following command:

netcat whois.cymru.com 43 < ip.txt > result.txt

Sample output:

Bulk mode; whois.cymru.com [2012-07-20 08:28:50 +0000]
8542    | xx.xx.xxx.xxx     | xx.xx.xx.xx/18      | NO | ripencc  | 2002-04-02 |
Internet service provider

You can read more about the service here: http://www.team-cymru.org/Services/ip-to-asn.html

Reverse DNS lookup with nslookup:

nslookup -type=PTR <IP in question> <IP to DNS server>


Security risk of embedding JWT in URL? I have a an endpoint, it redirects to an image which is stored on a storage service, I am considering if it is safe to embed the JWT in the url endpoint as such https://host/image?token=. This is the same JWT token which the system uses to decode and authenticate the user session. It works and allows me to ensure only a user logged into the system is able to access the storage url however does this impose any additional risks by placing the token in plain view instead of embedding it in the HTTP headers?
Thank you.

As designed, this makes your system significantly less secure.  That's because you've turned a token which authenticates an entire session and embedded it into a URL, where it is much more likely to be exposed, such as in browser history or in logs.  If that token is exposed, so is access to the entire user session.
What would be more secure is if you you created an authentication token that was restricted to that URL (say, by taking a hash of all of the remainder of the URL and embedding that in the token).  That would limit the scope of the exposure to access to that particular URL.
In addition, you should also make sure that either the JWT does not contain any identifiable information or that it is encrypted, so that if it is exposed, you haven't revealed potentially sensitive information about the user, and also you should limit it to the shortest possible timeframe possible to minimize the consequences of exposure.  These latter two options are best practices anyway, so you should consider adopting them regardless.
With those constraints, using some sort of authenticated URL isn't intrinsically insecure.  They're used with suitable constraints by many websites, including Amazon S3, and while putting the data in the header is better, using the authentication in the URL isn't bad.


Malicious programs that takes advantages of Windows vulnerabilities I was wondering if the majority of the viruses and worms are created to exploit vulnerabilities of the Windows system (not a third party app), also I would like to see a report.

In Windows a normal user is always (the majority of the time) with admin rights, let's say that the user execute a virus/worm, after it's executed with admin rights, why the would virus/worm would need to exploit a vulnerability? It's already executed, just check user == admin and just infect the Windows.

The question is:

Why would a bad guy will create a virus to exploit the system?

EDIT:

Allright, I know about UAC but as I said, some users are not educated, so it's not enough to be Admin user, the idea of a virus it's to get SYSTEM rights

Now which it's the purpose of a virus? why not just be a keylogger or the bad guy it's just a troll?

All these comes because I thought that virus programs just steal sensitive about the user, like keylogging or something, why it needs to exploit a vulnerability? I see too complicated to depend of a vulnerability knowing that the vulnerabilities are eradicated with updates

The goal of a piece of malware is to stay on your system for as long as it can.  To do this it takes a number of steps, and often just having user administrative privileges is not enough. Gaining execution is only one step.  If the malware is lucky enough for the user to execute it it can not assume that it has admin rights.  In which case, exploitation of a vulnerability is needed.  It can check Windows permissions, but the account permissions in Windows is a complicated subject.

At the point of having user admin credentials the malware can often write files, and registry values.  There are lots of persistence techniques that can be used, but writing registry keys or executing files on boot are among the easiest to detect and remove.  For modern operating systems you need to go further with SYSTEM level privileges.

Just being an administrator doesn't give you total access to the system, and the next level would be to exploit a vulnerability to allow SYSTEM level access.  This would give the attacker enough control to install a rootkit at a lower level.  Rootkits take many forms, and in modern operating systems it is getting harder to install these types of malware within the boot process.

Exploiting vulnerabilities takes many forms.  Not all vulnerabilities lead to remote code exeuction.  Some of them can lead to memory address leaks which are helpful in defeating ASLR, and some just give you an escalation in privilege.  Malware uses vulnerabilities for its specific purpose, and all of them linked together can create an annoying piece of software to get rid of.


Logging connections to hardcoded IP addresses On a Windows system, I'm able to get a good idea of most outgoing traffic by enabling DNS query logging, but I am missing those connections that are made straight to hardcoded IP addresses. What would be effective ways of specifically logging those connections?

The purpose is to get a clear picture of all outgoing traffic, and find out what portion of outgoing traffic is sent by a given endpoint to remote hardcoded IP addresses (thus bypassing DNS resolution).

Using native functionality in Windows, the best method would be to enable Audit Filtering Platform Connection. It can log all connections allowed by the Windows Firewall. The following is an excerpt:

  Audit Filtering Platform Connection determines whether the operating
  system generates audit events when connections are allowed or blocked
  by the Windows Filtering Platform.

  Windows Filtering Platform (WFP) enables independent software vendors
  (ISVs) to filter and modify TCP/IP packets, monitor or authorize
  connections, filter Internet Protocol security (IPsec)-protected
  traffic, and filter remote procedure calls (RPCs).

  This subcategory contains Windows Filtering Platform events about
  blocked and allowed connections, blocked and allowed port bindings,
  blocked and allowed port listening actions, and blocked to accept
  incoming connections applications.

The downside with enabling this auditing is the audit volume will be HIGH. Can't stress that enough.

From here you'll need a custom script or some other means to aggregate the DNS query logs and the Windows Filtering Platform (WFP) events to determine what IP addresses were accessed without performing a DNS lookup.

For example,

Build list of all unique destination IP addresses for a host.
Search DNS replies to that host for IP addresses from #1.

What you're aiming to achieve is difficult. Some application may use hard-coded IP addresses or other means to resolve a destination (NetBIOS, WINS, LLMNR, Bonjour, etc.). Depending on your environment, don't be surprised to find a number of false-positives during your investigation.

As an alternative, place a network monitoring device in front of the target system(s). Products such as Zeek (formerly Bro), Argus, SiLK, or RITA would all log network connections, in addition to other interesting data, and don't cost any money. In some instances they will even log DNS queries. This alternative approach will still require a custom script to aggregate the DNS query logs with network connections to find which were established without using traditional DNS.


SAML Without Session Is there a way to implement SAML-based authentication to an IdP where the client keeps the session information? The idea is that a load-balanced server farm for the SP would be able to remain completely state-less and not have to build a shared session cache.

After reading more about SAML, OpenID, and JWT, it seems that encrypting the authentication and authorization payload in a JWT, which gets signed provides assurance that the data it contains is valid and untampered. That is the same level of protection that the tokens from SAML and OpenID use. After that, the same problems of token theft that apply to every session management system exist and there are well-known mitigations for that.


What is a satisfactory result of penetration testing assessment? I'd like to ask you what should be satisfactory result of pen-testing job?

My main concern is that pen-testing is hard and it won't always result in gaining remote shells or roots. However, it is much easier to list potential vulnerabilities.

For example, if there's PHP version 4 from 2007 I can list it as potential vector but I may be unable to exploit it. Is successful exploitation a requirement for pen-testing job? Would vulnerability scan be good result of the job as well if there's some successful exploitation included (but accounts for less than 1% of all possible issues).

As someone who contracts pen-testers more than I act as a pen-tester, what I'm looking for is that you did more than run Nessus/ZAP/Burp - I can do that myself (though I expect that you do that as well).  I expect you watch the dataflows in the app/website and look for those loose threads that indicate there is a logic error that might be exploitable.  I expect that you are able to tell me what you can glean from the outside, that you can tell me things that cause concern that couldn't be found with a scan.

I'm looking for indications that you looked at, for instance, password reset screens and considered whether the flow is exploitable.  I want to see that you've considered whether privileged information is available to unprivileged users (ie, is the app just using css to hide it or something daft like that).

Ideally, I've done the easy stuff before I contract you - I've done the scan, I've done the patches and I've picked all the low-hanging fruit.  I hire a pen-tester for the hard stuff.

Really, if you don't manage an exploit, I want to see that you've worn your fingernails down scratching at the outside looking for a crack.


Security issues if I post username in comments on my website? When users try to log in to my web application they have two options: their username or their email including password, both of them are unique.

When the logged-in user tries to write comments in the public comment box, shall I post his/her username as a name or ask them to write their name? What can I do for better security?

If I post their username as a name, their account is at risk since a hacker can take the username and try to login with it.

A solution to your conundrum is having two separate handles for login and for display. Steam is a prominent example for this pattern. Users log in with their account name, while only the player name is displayed in forums or when playing with other users.

For this measure to be effective, you must ensure that those names cannot be the same. An attacker can harvest player names as much as he want, because only the account name can be used to log in.

You should be aware though, that user names are usually not treated as a secret and users are likely to leak them anyway. Your security should not revolve around keeping user names secret. A solid 2FA is all you need for state of the art user authentication.


Concerns discussing 'illegal' activities in a job interview Before I begin, I say 'illegal' because I guess the law is somewhat sketchy around the topic and that topic is XSS research.  Apparently people have been taken to court over it and UK law does have a section that covers it but still.

So, I have an interview coming up for my placement year as a penetration tester.  This morning I identified XSS vulnerabilities on 9 different websites without permission to search for those vulnerabilities.  They have all been verified and they're all reflected XSS.

Is there any way to slip this into the interview to prove that I'm sort of actively researching?  I mean, for everything else, I actively research in my own environments but that's somewhat difficult to do with XSS.

Any advice on how or even if I should bring this up?

Unless you are undergoing a polygraph examination (in which case you will have already disclosed pertinent answers such as 'have you hacked a system' and are merely being tested on truthfulness of your disclosures) then take the American attitude of anti-self incrimination (the 5th Amendment to the US Constitution).

During your interview, simply explain that you have researched x number of active vulnerabilities and are working with those clients to path their systems (or whatever you SLA with the 'researched into' companies is).

If you have indeed verified the XSS bugs and the companies have patched them, then look into disclosing them completely or at the very least look into having the companies you did the pentests for write you a recommendation letter confirming that you did the work.

Also, there is a distinction between legality and morality. The concept of what is legal and illegal is rather cut and dry (although judicial systems still debate this) whereas the sense of morality is highly subjective.


Would a recording of a complete GSM session provide a proof of authenticity? Hypothetical question: suppose I had a OsmocomBB phone modified to record all transmission done over GSM including encryption keys used during the communication. If I made a call and recorded all data transferred since the phone was turned on, would it be enough to prove that the phone call from one phone number to another took place? I'm interested in proving that without engaging the operator in this process.

If you mean "prove" in the sense of ensuring that the call is authentic and cannot be reputiadated by the other party then the answer is no.

Cellphone encryption is used only for the over-the-air portion of the call - between the mobile telephone and the base station. A GSM telephone has to authenticate to the base station but there is no guarantee the base station is genuine.


Charging someone else's cell phone in my car A sketchy looking person walked up to my car the other day while I was parking and asked if he could charge his cell phone in my car and offered to pay me $5. I didn't allow him to charge his phone in my car of course, but it made me wonder if there was anything he could have done (other than charge his phone) if I had connected his phone to my car's USB port. Anyone know if this is a scam of some sort?

Since I don't know your car model but you seem to be concerned about information security and the fact that the possible attacker chose your car I make the assumption that the USB port in your car is not power-only.

The telephone could do anything on this USB port because every USB device can identify itself as any device (storage, keyboard, network, display, ...). Have a search for bad USB.

The most critical attack vector is the bus system in your car. CAN is the best known protocol but there are others which are based on it like UDS (which is still weak from a security perspective). You can imagine it as a network in your car where all components can communicate with each other with more or less restrictions.

Here are some possible scenarios:

The USB port could be dual used as a maintenance port which could allow full access to the car bus system.
The car media system could have a vulnerability which could allow privilege escalation to the bus system. (By design the media system should be isolated from the critical components on the bus but in practice all vendors fail to do so.)
If you car supports some kind of wireless features for unlocking and starting, this could be a part of some exploitation technique.
The car could be used as a bridge between the attacker device and your phone (if it's paired somehow with your car via Bluetooth or WiFi) for some kind of attack against your phone.
The car media system could be infected with some kind of malware targeting your smartphone or other connected devices.
Malware which targets your car directly (like ransomware for example) would be also possible but I really really hope that this industry is not at this point yet.
Just to have a sneak peek for some details or to distract you for some reason.

Just to name a few. However. This is a very interesting question and attack scenario. Maybe I would have given this person $100 just to know their real intent in exchange for not calling the cops immediately.


How does malware protect its own malicious code from being exposed? For example, if a new rootkit starts spreading and reaches a malware honeypot, any skilled security specialist could get a memory dump of the system, find the malicious code and reverse engineer it, right? So what prevents known malware from being readily neutralized once they are launched?

I think the easiest way to answer your question is that most malware is coded using Polymorphic Code and the majority of Anti-Virus still uses signature based detection.

The reality is that a good chunk of the population does not keep their software up-to-date which means the original attack vector could potentially be re-exploited with a different payload. A lot of people put a lot of thought and effort into prevention, however not many put it into detection so once a box has been owned there's usually an avenue to re-exploit.


Is OpenPGP encryption a valid replacement for SSL when passing messages? I am writing an application that occasionally needs to transmit larger messages to other servers on the internet without allowing people to snoop on the traffic. The normal way to handle this is to get an SSL certificate and use an encrypted connection for the communication channel.

However, trusted certs cost money and I don't want to require my users purchase one to transmit data.

Currently, I'm trying to decide if using self-signed certificates or PGP would be a better idea. If I use PGP I can just have the servers pass each others public key back and forth before they send the data.

What is the proper way to use free encryption for something like this?

Why would you use PGP if you can just sign the certificates with your own generated root certificate and just add the public root certificate  to all your participating servers/clients?


What is the best resource to learn malware analysis? I am looking for a resource that helps learn malware analysis. I know about the practical malware analysis book but i am looking for something other than a book. For example a Site or video tutorials.

The Practical Malware Analysis book itself comes with hands on exercises for each chapter with solutions in the back of the book.  It's a great resource that you should probably invest in.

If you're not familiar with reverse engineering topics then I would suggest learning x86 Assembly, Windows Programming, and Windows Internals concepts.  Pick a debugger a learn it like the back of your hand:

Windbg
Ollydbg
Immunity Debugger

Pick up a free version of IDA Pro.  There are various tutorials on IDA's site.


Wireless security attack techniques Before I ask for some advice, please don't assume I'm a script kiddie or such. This is for one of my wireless security class (CSS 1015).

It's a Saturday class and only 6 students are in the class since it starts at 8:30 AM until 10 AM. Next week we are doing a lab where we bring in switches and routers and set up AP in the classroom (we are naming it CSS1015_1 and so on). The professor said one team will be the attack team and the other is the defense team. The defense team will have a small .txt file behind their AP and the attack team has to crack WEP and find that file (he calls it capture the flag).

I want to be ahead of the game when it comes to class next week. What are some tips/tricks that I should be doing with my attack team? Since it's our first time the WEP will be only 6 characters long.

There are a number of resources online, but I think you might find that the tutorials about Backtrack might be the most useful. You can run Backtrack on a live cd or as a VM on your laptop. The added benefit to Backtrack is that it will also have the tools to break into whatever host has the flag you are looking for.

Most tutorials will show you how to use aircrack-ng, so getting to know that tool will get you a long way.

Good luck on the exercise!


Is this an uncommon PNG ending or image steganography? I'm reading about image steganography at the moment. I got a test file to experiment with. I noticed a strange code block at the end of the PNG file when I opened it with vim:

xref
0 14
0000000000 65535 f
0000007361 00000 n
0000000019 00000 n
0000000209 00000 n
0000007504 00000 n
0000000229 00000 n
0000006570 00000 n
0000006591 00000 n
0000006783 00000 n
0000007097 00000 n
0000007274 00000 n
0000007306 00000 n
0000007603 00000 n
0000007700 00000 n
trailer
<</Size 14/Root 12 0 R
/Info 13 0 R
/ID [ <9AED3720B5C23ED368E99654D498CF4A>
<9AED3720B5C23ED368E99654D498CF4A> ]
/DocChecksum /B1C5AEC599F1457AC4BB4C058905BFD9
>>
startxref
7875
%%EOF

Is this a usual ending for PNG files or did I discover hidden (but not understandable) information?

That block seems to contain PDF syntax.

Here you can find information about the PDF format. The page provides this sample file where you might recognize the syntax for the cross-reference table (xref) and the trailer section:

%PDF-1.7
1 0 obj
  << /Type /Catalog
     /Pages 2 0 R
  >>
endobj

2 0 obj
  << /Type /Pages
     /Kids [3 0 R]
     /Count 1
  >>
endobj

3 0 obj
  << /Type /Page
     /Parent 2 0 R
     /MediaBox [0 0 600 400]
     /Resources << >>
  >>
endobj

xref
0 4
00000000000 65535 f
00000000010 00000 n
00000000069 00000 n
00000000141 00000 n
trailer
  << /Root 1 0 R
     /Size 4
  >>
startxref
249
%%EOF


Is this an exploit attempt and howcan I analyse it? Edited: Never mind the MinGW or .bash_history, I can see that is unlikely. Somebody attacking me and those bytes ending up in the frequently used file .bash_history by accident is not that unlikely however.
Is there anything legit that would look like this? The only thing I could think of apart from a NOP sled with canaries would be parts of a picture, but the fragment does not look like anything in an image editor. It also seems unlikely that somebody would paint a picture with mostly a #909090 gray

I do programming but nothing security related, and don't run any servers on my computer. I'm thinking the .bash_history might have been corrupted by the system when I had to do a CHKDSK /F a few days ago. But simply having had those exploit-looking bytes anywhere on my computer makes me nervous.

I use MinGW for compiling unixy stuff under Windows and to have unixy shell commands available. I often grep .bash_history to remember what parameters for various commands I have previously used. (Don't ask why I don't use the built in bash functions for this, just a habit)

I recently found in my ~/.bash_history a long run of binary bytes which consists mostly of 0x90 - NOP. In this are shorter runs of other binary bytes which assembles into mostly valid instructions.

A recurring run is 82 20 f8 7d 2c 61 0a de 90 90 90  [then 90... repeated]

Online Disassembler says

82      (bad)
20f8    and al,bh
7d2c    jge $+2c
61      (bad)
0ade    or bl,dh
90      nop
90      nop
90      nop
90      nop
90      nop
90...   nop... repeated

Could this be part of a buffer overrun attack, with the NOP sled? Don't know much about this kind of stuff, and can't see how these particular instructions could do anything or how they would be executed. But I also can't see how they ended up in my .bash_history or what else would produce data like this. I have reason to believe that only part of the data was "captured" by .bash_history so more obvious malicious code might have been left out and only the potential NOP sled remained.

They are repeated over and over with ~850 NOPs in between.

What do you guys think? If this is not the right forum, do you have any suggestions on where I should be posting?

NOPs are just padding. Your best bet is to perform a file analysis, or behavioral analysis (what does it call, what files does it load, etc) of the binary if you are that concerned. You could search the md5/sha1 checksums on sites like Virustotal, ThreatConnect, ThreatCrowd, etc. Since you mentioned you are compiling into Windows, my guess is, the NOPs are just used as padding in order to function under Windows. Again, to be on the safe side, upload it to Anubis, Virustotal before you waste time, if something extreme has been seen (open source translates to potentially thousands of downloads) someone has uploaded the file for strangeness


Truecrypt FDE and BSOD dumping physical memory to disk - possible data leak? I'm not sure what dumping physical memory to disk during a BSOD does exactly, but is there a chance that it dumps all data from RAM to the HDD un-encrypted, because I doubt Truecrypt works during a BSOD? On the other hand if the whole disk is encrypted there is nowhere to dump that much data as the whole disk appears full and RAM is a few GB's.

Most operating systems, including Windows, can be configured to write
  debugging information and contents of the system memory to so-called
  memory dump files (also called crash dump files) when an error occurs
  (system crash, "blue screen," bug check). Therefore, memory dump files
  may contain sensitive data. VeraCrypt cannot prevent cached passwords,
  encryption keys, and the contents of sensitive files opened in RAM
  from being saved unencrypted to memory dump files.

https://veracrypt.codeplex.com/wikipage?title=Memory%20Dump%20Files

This is no different for TrueCrypt.

As the links shows, memory dumps can be disabled.


How secure are wi-fi networks on a voucher system? Most people just put a WPA2 password on their Wi-Fi networks and move on. At my school, many people have managed to crack this system over and over again, to the point that they dropped that system and implemented a voucher system, in which users must input two five-digit passwords (characters 0-9 only), and this code expires after a preset length of time. Thus, there are, in theory, 10^10 possible combinations.

This is the sole security measure on the system; there is no physical key required, nor is there a WPA encryption on top of the voucher system.

For all intents and purposes for the sake of this question, assume I don't have physical access to the modem.

It seems that there are certain passkeys that work as dailies, certain passkeys that work as weeklies, etc., that are all pre-generated. I am unaware of the details behind how the vouchers are generated, but they seem to be pre-generated on a specific system and cannot just be generated when someone needs one. In all cases, the key can only be used once; for instance, if I have a passkey and type it in on my computer, it somehow will continue recognizing my computer until the key expires, but I will be unable to use that same key on my smartphone.

Do note that, taking all of this together, the following facts are true:

Not all of the keys are active at once, so although one can randomly select keys and hope he gets one, he has far fewer than 10^10 possible combinations that actually work;
Of the ones that are active, most of them are already being used and therefore cannot be re-used.
One would need access to the server to generate a new passkey just for them, and, as noted above, that's not included in the scope of this question.

There does not appear to be anything preventing someone from just working through all 10,000,000,000 possible combinations until he gets lucky and finds one that works, but I'm hoping for an answer that does not involve brute-force.

Is this actually that much more secure than a system in which the user doesn't know how many characters there are, and which each have much more than just 10 options for each character? How much would it take to hack such a system, to be able to use it without authorization? (I've purposely phrased the question so that ways to get in without a passkey are allowed for the sake of this question.)

There is an inherent difference between WPA2 which should authorize and encrypt, and a captive portal with some key, which can only authorize. If you switch off WPA2 you loose encryption over the air, which is a bad thing, since now people can spy on your transmissions.

So its like on Airport WiFi´s and other public places, do not use any communication which is not encrypted. Already before, of course, all people joining the WiFi with the WPA2 could do that.

On the other hand, was the other answer tells, the portal can help avoiding people joining over and over again with the same key, when they shouldn´t. In the end the best solution would be to have username and password login with a Radius server behind, to establish enterprise-grade user authentication and key exchange.


Ongoing Executive Impersonation Attack A friend of mine runs a small business that was recently targeted by a relatively sophisticated "executive impersonation" wire transfer spearphishing attack.  The attacker registered a domain that was a slight variant to the target company's that was visually similar, and spoofed a convincing E-mail to the company's finance department requesting a wire transfer to a provided bank account.  The domain name is registered through Google, whois information is anonymized through a proxy, and the E-mail was sent using the Google Apps' Gmail web interface.

Fortunately, the company's security policies were robust enough to catch the fraud before any funds were transferred.  One of the details about this incident that seems odd based upon what I've read about similar attacks is that the bank account was based in the United States, and is associated with a domestic address near the bank.

The relevant authorities were notified, including the bank, Google, the whois proxy service, police local to the target company, police local to the bank, the FBI, and DHS.  The police local to the bank seemed mildly interested, and actually visited the address associated with the account, but no one was there.  Among the other authorities, either they have yet to respond or they are uninterested in helping, since no actual money was transferred/lost.  The dollar amount was also relatively small for fraud like this (low five figures).

As of the time of this posting, the attackers are still being strung along and believe that the wire transfer will occur.

I have two questions:

Is it typical for these attacks to be associated with domestic US bank accounts?  Does that imply that the attacker is also domestic?
Given that the attackers are still actively engaged, and assuming the authorities are unwilling to investigate, is there anything that can be done to reveal more information about the attackers?  I realize that 419-style scam baiting probably won't work for a situation like this, and vigilantism is unadvisable, especially if the attackers are domestic.  But perhaps there is something relatively passive that could be done to help catch the attackers?

Update: One of the federal agencies finally expressed some interest and started guiding the ongoing communication with the attackers.

First off: notifying the police and three letter agencies that are responsible is exactly the right thing to do.

To your questions:

Not quite. But that does not mean that the attacker is US-based or that it's the attacker's bank account.

For all that matters, it could be the bank account of someone previously fished that has no relevant balance.

Using that as the destination for a wire transfer scam is tricky: it covers the attacker's identity and adds a false sense of security, as the destination account is with a US bank rather than some shady off shore bank.
No. Please just leave that to your government and the law enforcement agencies. Cross reference this question and its answers.


How do applications which are integrated using a javascript client side sdk, secure their data or disallow spam? Take an example of google maps. google maps provides a javascript client SDK, which means any web app running javascript can access the google maps sdk. You need to use an API_KEY so that google can rate limit your requests, and apply some quota on the requests coming from your api key. If you exceed the quota you would be charged more.
The API_KEY has to be specified in the client side javascript, so it would be visible to anyone who uses your application, and then anyone can abuse your quota. To get around this, google suggests to add referrer based security while setting up your sdk on the google app console. You can specify a list of origins that google would accept requests from, based on the referrer header. So if someone gets your api key and tries to use that from another web application running on another domain, either google would not respond to those requests, or, the request wouldn't be added in your quota. This acts as a basic level of security, BUT, the referrer header can be easily spoofed.
Now google maps does not have any user specific data, so may be API_KEY abuse is not that big an issue.
Consider an application like sentry, which allows a javascript client to send events to a sentry server. Sentry can also impose similar restrictions based on the referrer or origin header, and only allow events to your sentry server from certain domains. But wouldn't it be easy for someone to directly send events to your sentry and spam your sentry server?
Sentry suggests to not send any PII in the events anyway, so in case it was possible to get data somehow, at least the guidelines are clear.
But what about products like Intercom, where the primary functionality is collecting user data in some form or the other. If someone knows the unique id of another user in intercom, they can basically see all the data from the other user, their chats , their messages etc. Intercom is a completely frontend setup, where the request to the intercom script and the intercom server happen through the front end, so if the front end can get user's data through intercom, then any other user can get another user's data by initiating intercom with the other user's id on their browser or directly using curl. There is no auth as such, there is an app key which is also completely frontend.
I am just trying to understand how do such applications secure themselves?
Some points about intercom:

it opens in an iframe, with intercom.com domain
possibly the api has CORS restrictions, so only requests from intercom.com domain are allowed, but these restrictions are  not applicable for curl
it exposes some javascript methods to initialize with a app secret and you can pass a unique id for the user. The app key is frontend only so can easily be seen in any integration, and the user id can be leaked through other ways. Once leaked, I can just use this user id and the secret key from anywhere to get messages for the user.

Nevermind. Turns out intercom allows enabling something called Identity Verification, where everytime you initialize intercom with a user id, you need to also send a user_hash, which is generated using a secret shared between you and intercom and is an HMAC created using the user_id.
This acts as a password that you have created for the user to log in to intercom. The unique id is comparable to your user Id, and the user_hash is comparable to your password. So your id might be easy to guess or be used in different places, the password (although being sent over the wire for initial login) would be more secure, and wouldn't be used directly at other places.
This would make it impossible for one user to impersonate another user, as the secret can't be leaked, and if you try logging with another user_id using your user_hash, intercom would disallow.
https://developers.intercom.com/installing-intercom/docs/enable-identity-verification-on-your-web-product


How to investigate an IP address that was involved a security breach? I'm wondering what one can do if they have the IP addresses that were used by the attackers during a security breach?

The specific situation is this - recently two of our servers were hacked into and taken offline.  After we regained control I looked at the /var/logs/secure file and noticed a ton of messages like the one below:

  Jun 12 23:56:35 d3db01 sshd[31736]: reverse mapping checking
  getaddrinfo for host31-65-211-80.serverdedicati.aruba.it
  [80.211.65.31] failed - POSSIBLE BREAK-IN ATTEMPT!

That occurred right around the time of the attack.

Can I find information about the attacker and possibly use that to report them to the authorities?  Am I looking in the right place for information about the attacker or is there somewhere else I should be looking?

When you hear about high profile breaches they are often able to track the attack back to where it originated from.  I'm curious how that is done.

The "POTENTIAL BREAK-IN ATTEMPT" language in this log message was a frequent source of confusion, and was removed in 2016. The fact that you're still seeing it suggests that you are running an old version of OpenSSH, which should be upgraded.

The only thing that this log message means is that the IP address indicated in the message attempted to make an SSH connection to your server. If you weren't expecting a connection from this hosting provider, it's possible that there was an SSH scanner running on this IP. This is (unfortunately) quite common, and should be reported to the ISP, but it's not a reliable indicator that they were specifically at fault for the breakin.


Can I trust the details given in Resource Monitor? I'm looking at Resource Monitor in Windows 7 and wondered whether a process could be hiding in plain sight by mimicking another process. For example I've renamed an executable file as chrome.exe and when I run it it shows up as chrome.exe under the Image column, the same as Chrome itself - but the Description is different (it also contains chrome.exe).

What I want to know is can the Description column be changed to make something look like something else? Where is this Description field set from?

The "Description" is set the from the Title of the application assembly. I'll give you an example in vb.net:

It's from the "File description" property which has as "Title" in Assembly information in Visual Studio 2010.

And yes, that could be easily changed as I changed it myself right now.
I'd suggest for that you use Process Explorer from Sysinternals because it has a tab which displays if the process has a "Digital Signature" from a company like this:

which can be helpful.


How is the strength of a key/Password determined I was reading about the Principle of Key Sizes and came across this table:

The deduction I made off this is that after a certain key size, increase in a single bit causes Time required for search to get doubled from the previous one.

Then, I came across this video How to crack Passwords in which Prof. Pound tell's that your key strength is somewhat related to the character set of your password/Key.

For Instance if my password is of 8 length and its character set is lowercase characters, then total attempts required to crack my password will be 26^8 = 208827064576 (character_set ^ keysize) (on the worst case).

So I was wondering, whether the increase in Key_Size by bits, and this character set theory is somewhat related or not. If yes, then why most people measure strength of key by the number of bits it has, rather then the character set it uses?

And what is the most common character set used in password/key cracking, as most character tables (ASCII/UTF8) contains a lot of NPC's and/or Emoji's etc. so are they excluded during the key search process or not?

I think you might be confusing "size/length" with "entropy". The text string 123456, when encoded in either UTF8 or other common encodings (ISO-8859-1 or "Latin", etc.), will be 8 x 6 = 48 bits in length. However, its entropy will be... ridiculous. I can't even estimate it, all I know is that any script kiddie will definitely be able to attack you successfully with such a weak password. The "size/length" in bits is related to the encoding using for the text. The "entropy" on the other hand is related to the randomness, or in other words the number of possible combinations that an attacker will have to try to be able to guess it.

A key is just a series of bits: 011001100010101011101... In a 128-bit key of course there are 128 bits. If those bits are truly random, then you will have an extremely strong key, containing 128 bits of entropy. But in reality keys are often (but not always and not necessarily) generated starting from a password or passphrase, because people will need to remember them. How can you remember 128 bits easily? That's impossible.

So people will just pick a password, and then an algorithm called "key derivation function" will transform the password into a key (a series of random bits). So what happens is that an attacker won't try to bruteforce the generated password, because they know that it's impossible to bruteforce 128 random bits in a reasonable time. So what the attacker does is try to bruteforce your password, generate the related key for each password, and try. Your password is very likely to contain much less than 128 bits of entropy, that's why the attacker will try to bruteforce the password instead of the key. For example, a 12-character password containing random uppercase/lowercase characters and numbers is going to have 62^12 = 3.23 x 10^21 = about 2^71 = about 71 bits of entropy.

Attackers usually have dictionaries and are going to bruteforce passwords using the most common words and patterns, rather than trying all the possible combinations at random. So for example they might try abc123, dogcatbird11, 5tr0ngPa55w0rd, etc. They might try to include some common symbols in the possible character set, for example question marks, exclamation marks, etc. but leave out other less common characters. In the end, it all depends on how much time and resources the attacker is willing to waste. Bruteforcing all the possible 8-character passwords might be feasible, but as soon as the complexity increases the attacker will have to make some specific choices, unless they feel like waiting for centuries in front of their computer.


What's the common strategy for issuing OCSP requests I am currently defining a PKI for code signing certificates on an embedded device (without internet connection). I define the behavior of the certificate issuer(FW release authority) as well as the FW code which will authenticate the certificate of the public key used to sign it upon FW update, I want to define a strategy for checking revocation status of code-signing certificates issued by a CA. the general system will work as follows :

1.firmware code shall be signed by a private key(key#1priv)
2.The public key paired with that private key(key#1pub) shall be  sent in a csr (constructed by a HSM) to the CA and obtain a code signing certificate
3.CA's public key will be downloaded to the drive in a secured way
4.During FW update the FW will receive the certificate for key#1pub , authenticate it with CA's public key and then proceed with the authentication of the FW code using key#1pub

My question is:
In case the CA's private key was compromised, from my understanding , a csr shall be sent again to the CA and a new certificate shall be obtained signed by the revocated private key. according to what I understood from online reading , a OCSP request shall be sent to the CA is order to find the revocation status of the certificate according to its serial number , how does the certificate requester knows when to issue such OCSP request ? in other words , what is the common practice for a timing of sending OCSP requests to the CA?
Thanks.

I think you get it wrong. To describe the basic ideas of using a certificate agency and of revocation:

The CA should be locally trusted on the device by installing its root certificate on the device.
The CA issues the certificate based on the CSR.
The device can verify the trust into the certificate by using the locally installed root certificate of the CA.
The CA can revoke certificates it has issued. The revocation information are signed by the CA so that they can be verified using the locally installed root CA.
But the CA certificate itself can not be revoked. Since the root certificate of the CA is self-signed the revocation would have been signed by the private key of the CA itself - but the root certificate should be revoked because exactly this private key is compromised which means one cannot trust anything signed with this key. This means if the CA is compromised one has to remove it as trusted from the device. See How are root CA revocations handled? and Can a RootCA be revoked? for more information.

Thus, there is no way to check the revocation of the CA.
But one can check the revocation of the CA issued certificate. This should be done whenever the certificate is used, i.e. whenever the signature is verified in your case. Since this might be too often OCSP responses and certificate revocation lists (CRL) have some kind of life time and you might reuse the last result as long as it is still considered valid.


Unescaped data in div or p tags, but unable to exploit A web application takes user input and displays the data, without any escaping or encoding, in div or p tags. So if I provide  as input, the source would look roughly like this:

From this I would assume that the web application is vulnerable and that the script will be executed. That is usually the case, but I have seen a few situations (can't provide any examples right now, unfortunately) where that is not the case. The payload is not executed even though it is reflected into the page.

What explanations could there be for this behaviour? Are there some other form of XSS prevention that stops unescaped scripts from being executed?

I see a number of possible explanation for this mystery:

The browsers built in XSS protection stopped the code from being executed. Not sure if the payload would be reflected back in the document if this was the case, though. (According to Conor Mancone in Chrome the payload will be reflected in the source but highlighted in red when you choose view source.)
There is a Content Security Policy that stops inline scripts from being executed. Fire up the developer console, go to the network tab and see if you can find a response header named Content-Security-Policy.
The content is put into the document using JS. If you set the DOM elements text property (or use the jQuery .text() method) the tags vill not be interpreted as tags but also not encoded as &gt;. To see if this is the case, use view source and see if you can find your payload in the actual page source. If it is not there, it must have gotten into the document by means of JS.


Is it trivial to protect from double free just by LD_PRELOADing a custom malloc/calloc and free? Can't one just implement a malloc/calloc wrapper that adds the returned pointer address to a global hash table prior to returning, and then a free wrapper that checks for the presence of the pointer in the table prior to freeing (returning early if it isn't present, and removing it if it is), and then LD_PRELOAD these malloc/calloc and free functions with a program like Firefox, in order to protect from double frees? Is there a reason why the standard malloc/calloc and free functions don't use such a technique, or why there isn't a secure variant that is suggested similarly to how strcpy_s is suggested in place of strcpy?

No. The reason double free is a vulnerability is that the memory has been reallocated for something else before the second free. Any such wrapper would have no way of knowing whether the free was intended for the first or second allocation of memory at that address.


Google Authenticator - Showing someone my code I want to create a video. During the video I need to login in to some website. I will use the one-time code from my google authenticator app. Is it safe to show this one-time code to the people or should I rather hide it?

It should be safe, as the OTP will change quickly (don't show it on live-stream though) and OTPs are designed in such a way that knowing previous ones does not allow you to figure out the next. I would still not recommended showing it if you can avoid it, just to be safe.


Does knowledge of data structure compromise AES encryption? I'm considering encrypting a series of TAR archives using AES. Something I'm concerned about is the TAR format being quite predictable regarding field content and block sizes:

  Each file object includes any file data, and is preceded by a 512-byte
  header record. The file data is written unaltered except that its
  length is rounded up to a multiple of 512 bytes. The original tar
  implementation did not care about the contents of the padding bytes,
  and left the buffer data unaltered, but most modern tar
  implementations fill the extra space with zeros.

Should an attacker get hold of a big tarball with hundreds of files, is the AES encryption compromised?

First, AES is not something that you want to use itself.  AES is a pseudorandom permutation family, which is roughly academic cryptography jargon for ‘here be dragons—do not enter unless you are a wizard who can harness them’.

You want to use an authenticated cipher like AES-GCM or NaCl crypto_secretbox_xsalsa20poly1305, in which the dragons—along with other useful things—have already been harnessed into a useful security contract: if you pick a key uniformly at random and assign to each message a unique message number, for up to a gigabyte of data per message and about a terabyte of data total under a single key, then AES-GCM prevents an adversary who can intercept messages in transit from (a) learning what's in them in any more detail than their length, and (b) forging them.

(NaCl crypto_secretbox_xsalsa20poly1305 has a slightly better security contract—it's safer for much larger volumes of data, you can safely pick the message numbers uniformly at random, and it's designed to invite resistance to side channel attacks in software implementations, unlike AES-GCM.)

This security contract holds even if the adversary can choose the patterns of data in the message.  The modern standard for secrecy of a cipher (IND-CPA, or indistinguishability under chosen-plaintext attack, which authenticated encryption implies) requires that the adversary be unable to find any pair of messages whose ciphertexts they can tell apart with more than negligible probability, even if given arbitrarily many other plaintext/ciphertext pairs of their choice.