What are darknets, and how can they be used to provide security and anonymity in network communication?

As someone who has been heavily involved in one darknet (Anonet) and helped start another (Underlink, which is now mostly defunct), I will attempt to share my experiences and understanding of them here. Please feel free to edit this answer to provide additional details or to correct anything.

Definition

"Darknet" is a tricky word that has a few different definitions, the most general of which is a private network with internet-like routing between peers. This is a very broad definition; darknets vary greatly in their structure. Some examples of darknets include:

Anonet and Anonet6, an IPv4 and sister IPv6 darknet with the goal of being completely decentralized and anonymous
Underlink, an IPv6-only darknet built by former Anonet members, with a focus more on hobbyism rather than complete anonymity, and was more centralized than Anonet.
Seattle Wireless, a meshnet1  operating in the Seattle area.
Tor is a not like the sample darknet I will describe below, but falls under the definition of a darknet, as it is comprised of a series of exit nodes that route traffic2.

What a Darknet Provides

As the question notes, it's difficult to remain anonymous on the internet while retaining the ability to communicate with a large number of users. On the internet, every website you communicate with receives your ISP-issued IP, which gives them your approximate location, and can be used with at least some reliability to track your actions.

By contrast, darknets allow you to use an internal, non-globally routed IP address when accessing resources hosted on the darknet. Participants in the darknet, excluding your direct peers, will never be able to see your real IP address, but will still be able to communicate with you using virtually any peer-to-peer application (HTTP, email, BitTorrent, FTP, SSH, ...).

An Example Darknet

I will describe an example darknet. This should be enough detail for you to at least get started in forming your own darknet. You will, however, need to do additional research. There are many approaches to structuring a darknet, and you will want to make informed decisions as you plan yours out. Darknets are a great way to learn more about networking. I highly recommend participating in one to anybody interested in the topic.

Peerings

Darknets, like the internet, are built on the idea of peerings. Anyone interested in joining the network's routing infrastructure needs to peer with one or more existing participants on the network. This forms a redundant web of participants, allowing the network to expand.

In order to peer with somebody, all you really need is a direct connection to them (and their cooperation). You can connect an ethernet cable from their machines (or routers) to yours, or you can setup a virtual ethernet tunnel using VPN software3. The benefit of using virtual tunnels instead of physical infrastructure (ethernet links, wireless connections) is that your network can span the globe easily and cheaply. Using physical links limits you to participants in your physical area, limiting the potential size and adoption of your darknet. The main disadvantage of using virtual tunnels is that you remain dependent on ISPs and governments allowing you to have access to the internet4.

Routing

Assuming that you have managed to connect two machines together, I will now explain the most important component of a functioning darknet: routing. There are several types of routing you can use. Tor, for example, uses onion routing. For the sake of this example setup, though, we'll use a more traditional routing scheme: BGP routing5.

In a BGP routing setup, each participant is an "autonomous system" (AS). Each AS has its own set of IP space to do whatever it wants with. These ASes are identified with a number (an "ASN"), which is unique across the entire network (the internet or the darknet, depending on the context). You can see a list of AS numbers in use on the internet here.

Let's say I want to peer with my friend, chris (I am lex). We each have picked an AS number (I am 3090, chris is 404). In order to peer, we need to do just two things:

Establish a connection between our routers (often VPSes or generic Linux boxes hosted at some datacenter). We will probably use a virtual tunnel (VPN) to do this.
Configure our BGP daemons to advertise our peering to the rest of the network, and to establish routing with each other6.

Each network participant will typically want to have multiple peers to provide redundancy. This is, however, a security risk, because each peer will know your true IP address. As such, you want to peer only with people you trust (not just trust as a person, but also trust to keep their machine secure from hackers or the authorities to protect your identity).

A sample network map will look like this (this is an old visual map of the actual BGP setup on Anonet6):

Each bubble represents a participant doing routing on Anonet. Typically each machine here would get a /24 (the above map is of ano6, but I'll use IPv4 terminology because it's easier to grasp for more people), and be free to assign addresses inside that however it wanted; that machine would handle final routing for them.

So let's say that I am AS3090 (lex, in the middle). AS3090 is actually a dedicated machine in some datacenter. For convenience, all of my personal computers connect to my server using some standard VPN software (OpenVPN, in this case), and are given addresses on AS3090's /24. This way, my laptops/tablets/desktops, which don't have static IPs, don't have to worry about peering. They let the dedicated server handle that for them.

If one of my machines connected to AS3090 wants to send a packet to a machine in AS31416 (far right of the map), it has a few simple options:

AS3090 (lex) -> AS1112 (UFO)     -> AS31416 (JCS)
AS3090 (lex) -> AS404 (chris)    -> AS31415 (JCS) -> AS31416 (JCS)
AS3090 (lex) -> AS404 (chris)    -> AS405 (chris) -> AS31416 (JCS)
AS3090 (lex) -> AS2323 (achedaz) -> AS1112 (UFO)  -> AS31416 (JCS)

(this is just a subset of possible paths)

This is all part of the BGP routing framework.

The first path in my list is the shortest (in number of hops, not necessarily in terms of latency, since each hop could be, and often is, located on a different continent), so the packets will take that path there. The response packets may well take a different path back, but that's not important; as long as the packets get to the origin, the two machines can still talk. It's not uncommon to see outgoing packets leave on one interface and responses returning on a different interface. Your OS won't care.

The beauty of this setup is that it functions just like the real internet (in fact, core parts of the internet use BGP routing just like this). If AS3090 (lex) loses its connection with AS1112 (UFO), then the packets will automatically choose a different path to AS31416. It's redundant in this way.

Why This Provides Anonymity

This also makes darknets very good for anonymity. If I am AS12345 (dBZ, top middle), the only person on the entire network who knows my true IP is my only peer, AS1 (r101). The rest only see my internal IP inside AS12345's subnet. For authorities, or anybody else, to find out AS12345's location/IP, they have to follow the chain of peers and break each one to find out who they're connecting with. This can be extremely expensive on large darknets, since peers often cross borders (in Anonet, we often planned out to cross borders to make it especially tricky).

Growing Pains

This stuff is pretty easy once you understand it. The hard part in growing a network like this is that it's decentralized. Anonet split in half multiple times during its life. The peering between AS3090 (lex) and AS757 (Vutral) could break at any minute, and those two halves of Anonet would completely cease to be connected. But the people in each half would still be able to talk to eachother. You can cut the darknet in half and it still survives.

Typing in a friend's IP address to access their services (websites, file sharing, whatever) isn't fun. You want DNS, right? Well, that requires some central authority to make sure nobody is infringing on eachothers' claims. On Anonet, the way we "solved" that was with something called "resdb": a git repo containing a set of claims. Anybody could make claims and commit changes. The key was to get others to accept your changes into their copy of the git repo. This meant that different people had different versions of the repo, so for some people a domain doesn't exist, for others it does, and for others it might exist but point somewhere completely different. (resdb contained a set of files and scripts to generate zone files for BIND and similar so that anyone could run their own DNS server for the ano. TLD).

But you don't just need DNS reservations to be unique. IP allocations should be unique, too. Wouldn't we all like to be 172.16.0.0/24? If multiple people are using that, we get conflicts, which means that those go in resdb as well and you need to convince people to accept your claims. You also need to handle AS number reservations and a dozen other things that ICANN handles on the internet. It turns into a big mess and it's very hard to scale since there is no central authority which has the final say on reservations.

I can't stress enough how big of a mess resdb ended up being. Underlink attempted to solve these problems by sacrificing some of the decentralization of Anonet for the sake of convenience. There was a central authority that handled DNS registrations and ASN/IP allocations, and it worked pretty well for Underlink's short life (about a year). Underlink never took off, but I do think its model is preferable in many cases. It all depends on the central authority remaining benign and secure. The whole reason we started a darknet was that we didn't want to live under ICANN's rules. Both approaches clearly have merits.

Conclusion

I hope this gave you a bit of an idea of what a darknet is. Again, this is not a full definition, it's just based on my experiences, and a lot of it isn't really relevant to your goal. I know, for example, that some people have attempted to create darknets by using consumer routers flashed with DD-WRT (to connect geographically close peers together) rather than using the existing infrastructure on the internet.

If you have any questions, please feel free to ask for clarification. I'm no expert, but I have played around with this stuff quite a bit just out of pure interest.

If you have knowledge to add, please go ahead and edit this response. I've made it community wiki to encourage that.

1. A meshnet is usually defined as a darknet that operates over participant-controlled physical links, such as broadcasting wireless routers or physical network cables. By contrast, most darknets use the existing infrastructure of the internet, connecting peers via virtual tunnels (VPNs) instead of physical links. Meshnets are thus much more limited in size, but they do provide additional benefits.

2. This is a pretty big simplification as I'm not entirely familiar with how Tor operates, and the rest of this post is focused more on a traditional darknet that uses internet-like routing rather than onion routing.

3. In the past, I have used QuickTun, SigmaVPN, and OpenVPN. Really, though, any software which allows you to have a virtual ethernet tunnel with a remote machine will work. It doesn't even have to encrypt the connection (but this is a really good idea, and all of the software examples above do provide encryption).

4. While your ISP or government won't easily be able to tell you are participating in a darknet if you use encrypted tunnels (all they will see is an encrypted VPN connection), it will probably look suspicious, and they could certainly prevent you from making the initial VPN connection.

5. BGP routing is used in many darknets, including Anonet and Underlink. Onion routing, and other more exotic routing schemes, do have their merits, but they can make it a lot harder for people to join your network (support for BGP routing is widespread and standardized, since it's what the internet uses). BGP routing is both redundant and can provide decent anonymity, so there's no reason to write it off, but looking at alternatives isn't a bad idea.

6. An example BGP routing configuration for a peering looks something like this:

protocol bgp bgp_chris_underlink_core
{
        table underlink_core; # routing table

        local as 3090; # my ASN
        neighbor 172.16.10.1 as 404; # partner (chris') IP address for the virtual tunnel interface, and his ASN
        source address 172.16.9.1; # my IP address virtual interface

        # a series of filters to ensure chris can't send me bad routes
        import filter underlink_filter_core;
        export filter underlink_filter_core;
};

This example uses bird, but other BGP daemons will be configured in a similar way. I have only used bird, but there are many variaties of BGP routing software available. Since it's a standardized protocol, it's not necessary that you and your peering partner use the same BGP software. You could even use an enterprise-grade router with a proprietary BGP client against his $15/m Linux VPS running bird.


Exchange of encrypted files through a server

So basically, the server will generate a key-pair for each user that signs up. It will give the user the private key, and keep the public key to encrypt anything that it receives for the user. When information is sent to the server (in plaintext) for the user to obtain, the server will encrypt the data with the public key, and when the information is downloaded, the user will decrypt the data.

A server is just a machine on a network that is providing a service (service, server... haha). Some services include file hosting (FTP servers for example), website hosting (for websites!), maybe voice servers to host common voice apps like ventrilo, mumble, teamspeak, etc. As far as what kind of server you'd need, that depends a lot on how you want to go about it.

If you are using java/javascript, you might consider using a web server of some kind, and writing some custom scripts to automatically encrypt any files uploaded through your interface. This isn't my forte either, but that's kind of what it looks like.


Kerberos Authentication : Client authentication only

Removing the authentication component of this question for a moment you're asking "is X secure?" It's not a binary answer because you need to ask the question in the context of a particular attack or threat model, which is dictated by what the app is used for and who would use it.

That being said, this is a fairly common pattern and is often considered an acceptable off the type shelf solution. Web apps will not authenticate every HTTP request with a Kerberos ticket because each request would need to go through the WWW-Authenticate handshake, so the only way you can authenticate each request is by creating a session ticket.

Think of it this way... You're accepting a Kerberos ticket that can only be used once for a user from an authority you explicitly trust (the KDC) and exchanging that ticket for a session ticket you explicitly trust (because you issued it) that can be used multiple times. As long as your session ticket generation and validation is secure this is all probably fine.


The logs of the cloud service provider themselves would be the most valuable.  The cloud service provider is going to keep logs about the state of the system that extend beyond what is available to the user and would provide a lot of insight in to an intrusion.

Keep in mind that not all cloud services use virtual machines either.  They can be as simple as different users on the same service.  You are pretty much at the mercy of the cloud service's logging, but that generally will be better than private industry since cloud services have to focus on up-time for their business, which means finding problems early, which generally means extensive logging.


Malicious .scr file partially executed: sohanad?

First, an SCR file is an executable file so it could really have been any malware in existence. Failing more specific evidence you didn't share, there is no reason to believe it was the Sohanad worm. In fact, given you do not see any of the symptoms attributed to Sohanad and your virus scanner did not detect it as such, it was quite probably something else. It is most unfortunate you deleted it so now you have no way to find out what it actually was.

Second, there is no such thing as a partial execution. The executable was loaded and started, as evidenced by the fact that it popped up a message. If it was malware then there's no reason to believe it really sat idle while waiting for you to dismiss the message. It is quite possible that it had already started to compromise your system in the background.

Third, checking "several system executables" is not enough to assure your system is clean. If your system was compromised then malware may be hiding in any location. Not every malware modifies regular Windows executables.

Your safest course of action would be to reinstall the system from known good media. At the very least, perform a full scan of your system from an antivirus live CD.


Ways to protect phone from hacking through a wifi network when travelling

This problem is solved by using a VPN. Using a VPN, your data is not visible in plain-text to someone who is capturing the network traffic.

Depending on how "techie" you are, you have various options.

If you are not technology savvy, look for a VPN service. There are a lot out there, but product recommendation is out of the scope of stackexchange. Just be aware to not use any free provider.
If you are proficient with computers, you can create your own VPN server using a cloud provider (AWS for instance). A common software used in this case is OpenVPN. A good thing of AWS is that there is available a preconfigured virtual machine (AMI). Here you have a tutorial to set everything up.


How to handle a remote office and a client requiring IP Whitelisting?

I'm not sure if this is really an information security question per se or more of one about general networking; but here goes:

If you have a number of dynamic IPs connecting to a client that requires whitelisting, this will lead to constantly having to ping the client to update the ACLs to allow IPs as they change.   While on modern residential connections this happens infrequently, it's enough to be a disruption.

The way most companies deal with this is to establish either a bastion host or a VPN.

The Bastion Host

A bastion host is a secure, hardened server that is connected to by authorized users.  Its role is to allow these users to remote into it, and then "bounce" from it to connect to other, secure servers.    Of course, the bastion host would have a static IP (it could be a cloud server, for example).

Now, this is useful for SSH, Remote Desktop or similar connections, but when needing more robust network connectivity a VPN is often the right solution.

The full or split tunnel VPN

A full tunnel VPN is a VPN connection that makes all traffic from the VPN client go over the VPN.  Thus, all remote hosts/websites see traffic coming from the VPN concentrator's IP, and not that of the end user.

You can establish a full tunnel VPN at your site and have users connect to it.  Then, they can connect as normal to the client's server.  The client's server can only whitelist your VPN's public IP address, and thus any user connected to the full-tunnel VPN will be whitelisted and able to establish connectivity.

This system does have drawbacks in that it may cause slow connections on the end user's side, and slow down the VPN concentrator's internet connection.  You can also configure the VPN to be "split tunnel", and only send certain traffic over it.  In this case, you can specify that traffic to the client's servers IP addresses or range go over the VPN, while other general internet traffic go over the normal internet connection without traversing the VPN.  This will conserve bandwidth on the VPN side and lead to faster internet connectivity for users connected to the VPN.


Possible ways to intrigue IP blockage on practical websites

In general, it is uncommon to assign multiple people the same public IP address unless they share an institutional structure, such as a family, employer, or educational institution.  That isn't to say that it doesn't happen, since there have been reports of a Qatari ISP sending all its traffic through a small set of IPs and VPNs have this problem, but in general it's less common.
As a result, those institutions generally provide some sort of sanction to bad actors who cause problems.  For example, if you act inappropriately at the workplace, you may be fired and you can be held liable in court for any damages to the company caused by your inappropriate actions.  Usually targets of abuse are eager to help these institutions discover and sanction the responsible party because they want the abuse to stop.
I work for a major Internet site, and while it's certainly the case that a lot of low-level abuse may go unnoticed, when it does come to our attention, we act.  If the behavior is not urgent and the actor is known, we will often ask them to fix the problem, but we will block major abusers immediately without further notice if they cause availability concerns, sometimes sending an abuse report to their provider.  Sometimes this behavior occurs by accident as people frequently perform a normally rare activity very frequently and it's more expensive to our infrastructure than we expected, while still within rate limits.  A lot of abuse is just flagged by automated systems which restrict activities of the problematic users, and this kind of technique is frequent among large sites.
I suspect if you really want to do so, you can, in fact, get yourself blocked, and it may not even be very difficult.  You could simply create an automated system to inefficiently scrape user-visible web pages at high speed, which is a common problem for large sites.  I will point out that in all likelihood, if you do so, you will find yourself at the very least without future Internet access from the people with whom you share your IP, if not more significant sanctions.


What is the security implications of enabling SSH onward connections

There is no security problem with SSH agent forwarding per se; that is, there is no additional risk that you would not see by manually logging in to the remote server and connecting to a third machine.

The risk lies in the fact that a malicious system owner (or attacker, if the system has already been compromised) is in a perfect position for a man-in-the-middle attack.

The MitM attack could come from several different vectors, although two come to mind specifically. The malicious admin could attempt to sslstrip an outgoing SSH connection so that your data (including credentials) is readable in transit, or he could change DNS so that you are connecting to an SSHd designed specifically to steal passwords, rather than the destination you were initially trying to reach.

Again, though, these risks would be present while using a third-party server even without specifically using SSH agent forwarding.

Hope this helps :)


Is there no way to bypass certificate pinning without patching apps?

No, there is no way to bypass certificate pinning without application patching or using debugger (tracer). The reason is that, in simple words, certificate pinning is when a CA certificate is hardcoded into application. This application sets the certificate as the only root of trust to establish a network connection. On Android it's carried out via TrustManager implementation.

You have the following options:

Reverse engineer, modify and re-pack application.
Attach Frida to unpin certificate (e.g. there is a code snippet for Android).
Attach Frida to read traffic right before encryption.

You don't need root (superuser, jailbreak) using a Frida Gadget which should be injected into application before installation. E.g. see how to use Frida without root on Android.

Pay attention, that in some cases applications don't have a real certificate pinning. For instance, there is a known issue that Android applications by default have a trust to ONLY system certificate storage, therefore user's custom MITM certificate just doesn't work there by default.


This is an old piece of malware. Though technology isn't a panacea, if you're having this problem it seems like your technical protection needs an update.

If updated, I feel like offering that if it were easy to do this at a server it would already be implemented at the workstations: To identify files associated with CryptoLocker you need a signature, and if you have a signature you have an antivirus scanner. In this loop, the better your AV process is the fewer files (by signature) you'll get/keep on your server.

You can improve this by moving towards IOC-based systems, but that changes the game since you're in front of the signature vendors.

To keep CryptoLocked files off your server, scanners exist to help identify them at this question.


Yes.
Is there any reason you think this wouldn't work?


Is it safe to check if device is subject to Stagefright bug?

Yes, Zimprerium was the group that discovered and reported the StageFright vulnerability (here's the original blog post).

Zimperium's Sr. Director of Platform Research and Exploitation, Joshua J. Drake (the discoverer and presenter of StageFright) is a famous Android security researcher, and a former researcher for metasploit.

While I applaud being cautious, if you can't trust their test tool then I'm not sure what you can trust.


If you are asking the question "Is my password compromised" then you suspect compromise and should change the password immediately, as per NCSC advice. Don't second guess if the risk is high enough; just do it. (This habit is the price you pay for not having to rotate it every month, like the advice used to be.)

I actually did this exact thing the other day. Very irritating as it so happened I'd changed my pw the previous week!


Should a user have the ability to be logged in from multiple locations at the same time?

I personally do not see any security issue in the fact that the user can be signed in from multiple locations at the same time.

However, when this happens, it could indicate that the account is compromised, and used by another user at the same time. I think that the best solution would be to inform the user of the situation ("Hey, you are already logged in at another location"), and give him the choice to dismiss the warning, or to take action (typically change his password).

Obviously, it would be necessary to use stronger authentication before taking any action on the account.


Is the UK Parliament e-petition system trustworthy?

The petitions site is purely a mechanism to see whether there may be high enough numbers to support something, and if so, that something will be discussed in Parliament.

There are some checks and balances (for example 80,000 fake votes were identified and removed) but there is no need for a strong level of trust here, as nothing is decided by any of these petitions.

For the re-doing of the European Exit referendum, there are around 4 million signatories, and even with some level of fraud, the government already knows that it is something they need to discuss.

In summary - can it be trusted to the level required for this purpose? almost certainly. Can it be trusted to have no fraud? No.


Monitoring and filtering of arbitrary outgoing data

First you need to decide how you will identify this data - this is probably going to be the biggest issue and it is not necessarily technical.

Do you aim to tag all documents and files with a rating? This works for organisations that do tag ever single piece of data, as the gateway then just looks for the tag and acts accordingly.
Do you set a blacklist of data to block? For example sequences of 16 digits can be blocked as they may be credit card numbers. You'll get false positives, but it can work in some environments.

If you have that sorted, the gateway aspect is relatively simple - force all devices to connect through a proxy that acts as an SSL endpoint. As you stated, this is effectively a MITM. Many proxies, including squid, will let you prevent or allow traffic based upon various criteria, but in the FOSS space you may be limited in the complexity level possible. Those two options above should work though.

You may find that trying to run deep analysis of packet streams in order to do this real time may be beyond the reach of FOSS (Have a look at next gen firewalls such as Palo Alto for some options here)


After decompiling the app and going through the source code I found out that it cannot be escalated to XSS because it's using Html.fromHtml TextView


Connect msfvenom reverse shell without metasploit

Why netcat is NOT working here?
To connect reverse shell created by msfvenom, any other way than
metasploit?

That's because you are generating a fully fledged meterpreter payload and using that is extremely different from a simple reverse shell. A simple reverse shell is a just a textual access to the cmd/bash but a fully fledged meterpreter payload contains not just shell access but also all kinds of other commands sending and receiving. In simple terms netcat cannot interact on a text basis with meterpreter. You could use the shell_reverse_tcp payload instead of meterpreter and then receive a connect back to netcat but not with meterpreter/reverse_tcp.


Is there a way to find out how long it takes John the Ripper to crack a particular password?

The important thing to understand is that password cracking time is an average. The attacker will try a lot of passwords, and may be lucky... or not. John the Ripper will use the provided word list, and then try "variants" of the said words, in some order which may or may not be representative of what an attacker will do.

If your password is chosen "at random" (uniformly) in a set of N possible passwords, then the average attack time will be the time it takes to compute N/2 hashes (with whatever hash function is used in your specific situation). This means that if you generate one million such passwords, and each time get the attacker to crack the chosen password, and then sum up all the times taken and divide by one million, then you will find that average times. Sometimes the attacker was faster; sometimes he was slower.

Or, said otherwise: no, John the Ripper is NOT the much fabled "password meter" which will give an absolute "strength value" to your password. The strength of a password is a property of how you generate it, not of the password itself. For any given password, you can only reason on averages and pray for the best.

The whole idea is that a password which is sufficiently random (more correctly, a password which is generated from a sufficiently random process) will bring the probability of an attacker getting lucky sufficiently low to be neglected (if the attacker has only one chance in 14 millions to get the password within one week of computations, then you can even out the chances by buying a lottery ticket, which has one chance in 14 millions to make you rich enough to ignore those trivial matters of stolen passwords).


How to prevent access based on MAC Address in local network and internet?

I can change my mac address, so I wouldn't depend on addresses. Addresses are like names, not like passwords.

I probably would use ssh keys, such as described at https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Deployment_Guide/s2-ssh-configuration-keypairs.html for Red Hat. There are other articles for other OSs.


How to store passwords to a remote web site?

Your current solution would work, however, you could keep the information on your server by tracking a session.  When a user sends their login credentials, you could store them in a database (possibly encrypted) and then issue them a unique session id (should be difficult to predict the session id, eg. crypto rand + hash).

Once the user has obtained the session key, they would send that id along with every request to your server.  When you verify that this session key is valid, you get the username/password out of the database, and make the request on behalf of the user.  After some amount of time, you'd invalidate this session key and delete it and the login information from your database.  This would help guard against replay style attacks.

If you include the actual login information and don't have some kind of age off, an attacker could obtain the URL used to access the system, and possibly make requests on behalf of the user.  Of course, this depends on how you set up the URL etc.

Typically though, this sort of situation is handled by storing the credentials locally in some sort of secure (e.g. encrypted) storage, and issuing some kind of temporal session identifier.

While there may be some benefit in using short running processes, it is likely more cost than benefit.  If an attacker is to the point at which they can read memory in your processes, the fact that the time in memory is short lived won't help much.  Furthermore, you are still probably storing the encrypted credentials somewhere on your server (e.g. http access logs), along with the encryption key (which I'm guessing is in a database).  If the attacker has access to both, the credentials will be compromised.  Depending on which language you're using to write application, there may be some way to zeroize memory once you're finished with the sensitive information.

If you use timestamps in the URL, you're going to need to make sure that the timestamp can't be tampered with (HMAC, AES-GCM etc).  Keeping credential data, encrypted or not, also represents a problem controlling information.  If you suspect your encryption key has been compromised, you can easily delete the credntials from your server.  If the credentials are in URLs potentially scattered all over the internet in browser caches etc, you won't be able to mitigate the leakage.

If you store the credentials in the database, along with whatever material you use to derive the key, you'll have much more control over the data.  Assuming you have your database application secured, it is arguably more secure.  I would suggest using different keys for each set of credentials, and using some kind of KDF (http://en.wikipedia.org/wiki/Key_derivation_function) to derive the key, instead of storing the key in plaintext in the database.  You could also include some portion of the key derivation material in the session id you issue to the user.

Of course, if someone has complete access to your server, including the database and/or the VA space of your CGI processes, the credentials will be comprimised, but that is true with nearly any solution.

If I were writing this application, I would use session ids to tie a user's requests to a set of credentials.  I would use a database table containing fields for the id, creation time, last seen time, username, password, and key derivation seed (this part depends on how you derive keys).  The session id I would issue to the user would be a large, hard to guess value (stored in the id field), combined with a portion of the material needed to generate the key (this material wouldn't be stored on the server, so both a valid session id and the material stored on the server are needed to decrypt the credentials).

For instance, a session id may look like this:

d7be62755db80ccefb7d802fde153145b6e9_bdb8f9bf599293fd65a020dba1ecd

The first part would be the id portion, and the second half part of the data needed to derive the key.

When a request is made, the id portion of the session id would be verified, and the decryption key generated using the key material portion supplied by the user (via the session id) and the portion stored in the database.  Once the key is generated, you'd decrypt and use the credneitals.

This way, if an attacker gains access to the database, they don't have everything they need to decrypt all of the credentials.  They'd need a session id for every set of credentials they wish to decrypt.

In order to age off sessions you could have a cron job, or some other mechanism, deleting expired sessions from the database.


POODLE is a vulnerability in the SSLv3 protocol, specifically in how it handles padding for block ciphers (RC4, being a stream cipher, isn't vulnerable, but it has its own weaknesses).

Do the client and server talk to each other using SSLv3?
Can a man-in-the-middle attacker coerce them into talking using SSLv3?

If the answer to either of the above questions is "yes", then the client/server pair is potentially vulnerable.  Actually performing the attack depends on the details of how the client and server work.


If you have a look at /var/run/docker.sock, you'll see that it's owned by root UID, and docker gid.

# ls -la /var/run/docker.sock
srw-rw---- 1 root docker 0 Jun  2 11:37 /var/run/docker.sock

Changing group ownership to your own group may stop docker from working properly, as it relies on the docker group for other functions.

The proper way to handle this is to add your users to the docker group. This is detailed in the post-install documentation. Note that giving a user access to docker is more or less equivalent with making that user root. If you have docker access, becoming root is extremely trivial:

  First of all, only trusted users should be allowed to control your Docker daemon. This is a direct consequence of some powerful Docker features. Specifically, Docker allows you to share a directory between the Docker host and a guest container; and it allows you to do so without limiting the access rights of the container. This means that you can start a container where the /host directory is the / directory on your host; and the container can alter your host filesystem without any restriction.


How safe is using personal Gmail and Google Account at work?

You can monitor anything in a network you control. So that means private webmail can be monitored by your employer.

Legally (us) they are allowed to do so when using company equipment or resources.

Monitoring is usually done on traffic, so all info on every page you load is susceptible to interception.
This does require specific software and quite a lot of time, so is only done by larger companies, or in case where a specific employee is suspect.

So Stay on the safe side and don't use private mail if you have a reason to believe your employer is interested in you in ways you don't like. Use your phone (not via WiFi).


Are these log messages in my nginx server evidence of an attempted attack?

AFAICS don't worry.

This seems to be an Attack which does not affect NginX.  Also I do not think this is a targeted attack, as I can see similar requests on my webservers, too.  Hence it looks like some of those automated vulnerability scans to exploit something somewhere.

GET requests do not have a body, so a content-length of -1 is for representation selection.  So this were just some small GET requests and not the indication, that somebody tried to upload 4 GB to your site.

For GET this type of request does not mean "I want to send you a 4294967295 bytes body", instead it is the request for "please answer me with 4294967295 bytes", which your server apparently declined.

Also 4294967295 is 0xffffffff or -1 for 32-bit signed integer, so on 32 bit it might trigger some DoS or any sort of NULL pointer trouble in the attacked script.  Even on 64 bit it might be that msdn.cpp mis-behaves when it interprets the content-length.

Please note that with a quick glimpse I did not find any source for some possible file named msdn.cpp on the web.  So it is unlikely that it is widely deployed.

Hence such requests might be a way to try to locate some already installed backdoor which obfuscates as msdn.cpp.  If it resides on some NAS/IoT device which is behind a dialup line, it might change the IP address daily, so perhaps somebody wants to search for it by scanning the whole web.

There are only roughly 3 billion IPv4 addresses to scan.  So just 50 machines with a query rate of 1000 requests per second can scan the entire IPv4 space in just one day, and 1000 req/s (of 1 KB each) only need a moderate uplink of around 1 MiB/s per machine.

There is no need for a BotNet to do this.  10 VMs cost you around $1 per day.  Easy.


to question number 1, yes and no, there are virus scanners that utilize the OS-index for files to scan (almost all of them), and there are also scanners that can ascan your "flash" bios and RAM for infections (malwarebytes i.e.).

and then there are scanners that scan the complete disc, which takes far longer, and is not OS dependant (i forgot the name for this one, if you know it, yell it in the comments so i can add it!!).

most of those are run at boot, as in, as a boot-disc, take hirens Bootdisc for example, where i work, when we get a infected PC, and cant solve it in the OS itself, we use a bootdiscc with a virus/malware scanner that scans the whole DRIVE, and not just the INDEXED part (includes hidden volumes, but not encrypted ones, ofcourse).

and to the second question, no, i dont know where to find those docs, may the good god of google shine his eternal light on you


Someone with root access could do any of these things anyways.  You cannot hide from root in unix-like OSes.  They have full control of the kernel, meaning they could, if they like, look at everything on any virtual terminal (ie, anything you type or see), examine any network traffic, examine process spaces - any OS level blocks can be bypassed by them - by patching the kernel, if by no other method.

Do not host your private keys anywhere you do not trust root.  If you do not trust root, you cannot trust the hardware, the OS, the shell, the applications...


PHP hack base64 code uploaded and sending mass emails

This most likely means you or your users are using outdated software / applications. The only way to prevent this, is to regularly update and patch this software / applications unless the hacker is using a 0-day exploit that's currently unknown.

Try determining the entry point where this script is uploaded from the web server log files. Once found, inform your user(s) to patch their software / application(s).

If you think you should block this at the "SMTP level", I think you are wrong. When hackers are able to upload and execute malicious PHP files, your server may be (partially) compromised. Try determining the root cause instead of fixing it somewhere else.

I suggest to investigate how much of the server is compromised by means of log files. Worst case, I'd suggest to start from scratch.


Wrong password - number of retries - what's a good number to allow?

Unless you have separate means of restricting access to the login form itself, a good baseline is don't have a hard limit. That's because it's way too easy for someone to be completely locked out of their account.

This is bad because of the denial of service, obviously, but it's also a security concern in itself. It will increase support requests from people asking for their accounts to be unlocked, and the people doing the unlocking will become habituated, and social engineering attacks starting with "hey, my account is locked" become that much easier.

Instead, extend timeouts — but not infinitely; just enough to restrict the number of guesses to a reasonable amount over time given your password complexity requirements.


What are the security features of the Microsoft PasswordVault class?

the PasswordVault uses the Windows.Security.Credentials namespace. As of today, this namespace is unavailable in Mono. so the other most popular cross platform compiler just won't work for this feature.


Why initiate this phishing attempt as an email?

I believe that this is attempting to take advantage of a flaw in an older version that would spawn numerous copies of that message, leading the user to believe the only way to remove it was to call the number for tech support. The message was never intended to be mailed, so the address was never important.

https://apple.stackexchange.com/questions/267132/ios-safari-repeatedly-opens-virus-detected-emails

You should probably update your IOS if you are getting this.


Are there approaches/mechanism to detect hardware backdoors?

You'd probably have to go around a lot of places to get anything specific, but since you are talking about hardware-based exploits, you're going to want to look for physical bugs. There's a great article I read from spiderlabs about some stuff like this: http://blog.spiderlabs.com/2014/03/detecting-surveillance-state-surveillance-part-1-hardware-impants.html

There are probably a LOT more on the internet, but a lot of looking for them involves searching for unaccounted radio transmissions if I recall.

Edit: As far as testing for specific backdoors only on ANY piece of hardware, that may be impossible.


Setting up router password AFTER malware infection?

As always, it depends. The right mitigation depends on the situation. In your situation (home user), I'd say just overwrite the firmware with the latest original version and reconfigured everything with a administrative password in place.

Configuration

During configuration consider things like "Strength of Wifi and administrative password? Is uPnP necessary? Or WPS? DMZ? Do I use WEP/WPA instead of WPA2? Setup a scoped Guest network? What Firewall options do I have?"

Back to basics

Make sure it's the original firmware you've downloaded (using a checksum check). That basically ensures that you have the original firmware running and not another version with a backdoor.

Risk (likelihood / impact)

Was it a router in a highly confidential area? Then, I'd calculate the risk based one the likelihood and impact (possible damage) and possibly consider to throw the router away and setup a new one.

What's next?

Also keep in mind that not only the router here is the potential risk. Make sure you audit the configurations and scan all your devices in the network accordingly.


Security risks on given session infrastructure

Length Extension Attack

What you have is basically a MAC to verify your user_id value. The problem is that a primitive MAC like MAC = md5(KEY | MESSAGE) is vulnerable to length extension attacks.

This means that an attacker with the user id 1 could for example impersonate a user with the id 10 by just appending a 0.

At a minimum, you would need to use a proper HMAC or use a non-vulnerable hash function such as sha3.

Token Expiration

If you store no state on the server, you have the problem of not being able to revoke a token.

So if a user for example changes their password because they suspect a compromise, an attacker that gained a token beforehand can still use it. You have no way of invalidating it, and need to wait until it expires naturally.

Solutions

What you seem to be looking for are client side sessions. You may want to consider using existing solutions such as JWT or some other existing library.

Further Problems

As @0x23212f said, your scheme obviously does not replace TLS and will not protect you from man in the middle attacks.

Aside from that, you should consider if you actually need client side sessions. If - as you suggested in the comments - the only reason is to avoid one database query, it's probably not worth the trouble implementing it, or the additional network overhead.


You could read the latest IT Security's blog post which talks about a similar topic. It's a interesting read and you might find some answers, even if your scenario and the one they are analyzing are a bit different.

The point is, there are many possible consequences to bear in mind when hacking a website that requests to be hacked, if you want to hack a website that doesn't request to be hacked and then notify them, you should probably be even more careful.

Of course, I am no lawyer, so for any more specific questions I suggest you to talk to one.


systemd-boot has to be signed as well. The original signed gummiboot respects the 'secure' boot process and requires that the binaries it is to launch are signed as well:
https://www.rodsbooks.com/efi-bootloaders/secureboot.html

So it's not quite that trivial.
But there are attacks on a different part of the boot process (called Secure Boot by Windows, but not part of the UEFI Secure Boot) that do override some protections:

https://www.ghacks.net/2016/08/10/secure-boot-bypass-revealed/
http://securityaffairs.co/wordpress/50182/hacking/backdoor-keys-uefi-secure-boot.html

The very term secure in relation to x86 architecture is always relative; It has to be viewed like car crash ratings - no car is crash-proof, some just take a bit more force to make it fatal.

This is to some degree inherent to all security, but with other designs there's a steep S-curve from "open wide" to "need an an electron microscope and a focused ion beam to crack". The efforts to secure a x86+Windows system are akin to plugging every hole on a sieve to make it seaworthy - with the proviso that every plug must open automatically when some legacy feature depends on the sieve's original function of letting the water through.


How fast can hackers change their IP address?

Botnet
If someone has access to a botnet, even a small one, they could change the IP that their actions are coming from several times per minute or flood their actions from a million IPs in any given moment.
Non-botnet
For individuals without a botnet, there are several methods, including resetting their ISP modem, which, in some cases, resets the IP. Turning a phone's airplane mode on/off can also trigger a change in IP (MechMK1 reports this might take as little as 3 seconds to complete).
They could also change between public WiFi networks.
Using a series of VPNs and proxies or VPNs that permit the user to choose the exit node will also work, and services that have different exit nodes can make this switch in seconds. There are also proxy/Tor utilities that can randomise your IP according to a schedule you set. The Janus tool has a default change time of 1 minute, but that can be changed.
Therefore, for any practical case, if the attacker is waiting for the SMS code to come back from your server, then they are only limited by the time it takes to receive the SMS code.


How to convince a university to address a serious security threat?

Most universities have a cyber security team or at least person, often attached to their IT department, to report findings like that. If all else fails, Call their help desk and ask who to report computer security problems.


This is the "1/n-1 split" technique which has been deployed in SSL libraries as a workaround for the BEAST attack.

The BEAST attack is the application to a Web context of a chosen plaintext attack. The attack works when:

The encryption uses a block cipher in CBC mode.
The attacker can choose the data that gets encrypted (in a Web context, this is done with Javascript).
Right before sending his bytes to encrypt, the attacker knows the IV that will be used with CBC mode.

In SSL 3.0 and TLS 1.0, the IV for a record is the last encrypted block from the previous record, so the attacker can see it by spying on the line (the attack setup supposes that the attacker can eavesdrop on the line and send information to some evil Javascript planted in the victim's browser -- this is realistic in the "WiFi in a restaurant" scenario, with an attacker-controlled access point).

The "1/n-1 split" prevents the attack because the frame with 1 byte includes a MAC value, that the attacker cannot predict, and that gets encrypted as well. The subtlety is a question of timing: when the attacker gets to choose the data which will be encrypted, neither the "1" nor the "n-1" records have been emittted; only when the attacker has pushed his n bytes will the two records be computed and sent. The net effect is that the attacker will not be able to know the IV for the n-1 record before sending his n bytes to encrypt. The attacker will still be able to predict the IV for the "1" record, but one byte is not enough for the attacker to pull off the BEAST attack.

Theoretically, a "0/n split" would be possible (a first frame with no data at all, then the actual frame) and would be even better (in an academic way), but, though it is supported as far as the standard is concerned, a number of deployed implementations choke on empty records, so the "1/n-1 split" is deemed more practical.

The BEAST attack also requires that the attacker gets a lot of control on the bytes he needs to send, e.g. he must not be restricted to only ASCII characters; the prototype attack relied on a pair of extra vulnerabilitiies which have been fixed since, so even without the 1/n-1 split, the attack would no longer work. But SSL library designers are cautious and don't want to see the SSL security being jeopardized by a vulnerability in another component of the application.

TLS 1.1 and later versions are immune because their record header includes a record-specific IV.


Are e-mail accounts considered generally insecure to receive sensitive information?

Email as a communication medium is generally considered to be insecure; the core protocols were not designed with security in place, and while secure protocols have since been layered on top of it, the nature of email means it has to be designed to "fail open" - everyone expects their email service to be able to send to anyone with a valid email address, so if they don't support TLS then you can't use it. And of course there is the problem of forwarding: once you send me an email with sensitive data in it you have lost control of it. I can forward it or print it out.

Your question mostly comes at it from a slightly different perspective - what about the email mailbox as a secure place to store data. There's not really an answer to that one, as different pieces of email software store the mailbox differently. Most of the modern ones will use decent technology to secure the actual mailbox database. On the other hand, the most popular cloud email services all make their money by reading your email and using the information to sell targeted advertising, which is not good for security.

In general, email accounts get hacked a lot because a) those are one of the best things to attack - "I rob banks because that's where they keep the money" and b) because they are secured with passwords and humans are rubbish at passwords. It's not really that they are inherently insecure.

Email based password resets are not ideal, but customers find them convenient, and they are cheap at scale, so we're stuck with them.


The basic idea is to include a secure random token with ever request such that it cannot be guessed before hand by an attacker.

OWASP recommends you use :-

  We recommend token based CSRF defense (either stateful/stateless) as a
  primary defense to mitigate CSRF in your applications. Only for highly
  sensitive operations, we also recommend a user interaction based
  protection (either re-authentication/one-time token, detailed in
  section 6.5) along with token based mitigation.

It goes into detail here

You also mention it's a .net application.ASP.NET core already already has in-built protection.The details of which are here


I have a custom domain for email. Do I need to configure DNS to prevent outgoing text messages with an address from my domain?

Only using SPF, DKIM and DMARC does not protect you from spoofing addresses.
SPF supports "fail" and "soft fail". Some mail providers are using "soft fail" because it is like a debugging flag, which means "the sender is not valid, but i will accept it"
If you want to stop spoofing, you should use "fail" in your spf record. If you import the rules from your provider, you can override the qualifier. Only the last qualifier is important.
With SPF, the attacker should not able to use a different server. If you are in a hosted environment, another user can spoof your address, if the server does not check, if the user is allowed to use the mail address.
In 2020, Google was affected by such a vulnerability: https://ezh.es/blog/2020/08/the-confused-mailman-sending-spf-and-dmarc-passing-mail-as-any-gmail-or-g-suite-customer/
Using DKIM and DMARC, the server signs your email and the recipient can be sure, that the email was sent from a valid server and the user was allowed to send emails with this address.
RFC-7489 (https://tools.ietf.org/html/rfc7489) in chapter 3.1 is the behavior of DMARC and the "From:" field defiend.

Thus, this field is the one used by end users to identify the source
of the message and therefore is a prime target for abuse. Many
high-profile email sources, such as email service providers, require
that the sending agent have authenticated before email can be
generated. Thus, for these mailboxes, the mechanism described in this
document provides recipient end users with strong evidence that the
message was indeed originated by the agent they associate with that
mailbox, if the end user knows that these various protections have
been provided.

This means, if you are using SPF, DMARC and DKIM, the sender field "From:" is trusted.
The DKIM signature is not like S/MIME or PGP, it is a server signature, which only protects the headers and not the body of the mail..


gpg --quick-generate-key user-id [algo [usage [expire]]] - Any way to include a comment?

It appears to work like this:
gpg --quick-generate-key "MyName (MyComment) <my@email.com>" rsa1024 cert never

At least, when you do it that way, the --list-keys output appears the same as that produced by a key generated with  --full-generate-key, which individually prompts for Name/eMail/Comment to create the UID field.


Use delay with a fixed total time to defend against timing attacks

TL;DR
I don't see anything in your provided code that would need to be protected against timing attacks. The purpose of timing attacks is to learn the plaintext secret, but since your code does not handle the plaintext secret (only a hash of it), your code couldn't leak the plaintext password even if it wanted to.
Technically your hash comparison should be constant time, but see below for why I'm not worried about this in practice.

Background on timing attacks
Let's take a step back and ask what timing attacks are trying to prevent. With passwords, as with all of crypto, you are trying to exploit timing differences in the function that is handling secret data in order to learn the secret.
The classic example is testing for equality between a stored password and a provided password using lazy string compare:
boolean compare(String str1, String str2)
   for (i=0; i<len(str1); i++)
      if (str1[i] != str2[i]) return false;
   return true;

Here you can learn the password one character at a time because when you get the first character right, the string compare will take slightly longer.
What about hashed passwords?
What if you are comparing password hashes rather than plaintext? In theory, if an attacker learns the first character of the password hash, they have gained information, so that is technically an information leak. However, in practice, a timing attack against hashed passwords would require the attacker to submit password candidates p where they can control hash(p) one character at a time (ie first a*, then aa* ...). This is hard. In fact, finding a plaintext whose hash has a given prefix is exactly the cryptographic problem that keeps bitcoin and blockchain secure, and that's on SHA-256; doing it on PBKDF2 or Argon2 would be even harder.
Does your code need to be constant time?
Given the argument above about handling password hashes, it doesn't really matter if this line is constant-time or not:
return verify(password_hash, user.password_hash)

It also does not matter at all whether this line is constant-time; who cares if they can learn password through a complex side-channel attack, they just submitted it to you, they already know it.
password_hash = slow_hash(password)

IMO it also doesn't matter whether your DB queries are constant time. The attacker would be learning how full your DB is, how much backend network congestion and server load you have, etc, none of which helps them crack passwords. (if your product security model does want to protect info about backend load, that's a much harder and completely separate question).

Bonus: adding random delays
While not directly mentioned in your question, I've written before about how adding random timing delays increases the number of statistical samples (ie the number of login attempts) that an attacker needs in order to perform the statistical attack, but it's ultimately not a solution.

Can I prevent timing attacks with random delays?


DNS Poisoning? Unable to access a specific website

DNS Poisoning happens when DNS queries are modified by attacker's needs.

To check whether your DNS queries are poisoned, you can check with the following steps.

Run nslookup <target site>
Google online nslookup and do an online nslookup.

If your local nslookup does not match with various online nslookup results, it is highly likely that your DNS queries are monitored and modified on the fly.

If your government or ISP is monitoring the DNS, it is likely that you can't benefit from using 8.8.8.8 or 1.1.1.1 because DNS queries are not encrypted and it can be directly modified from the ISP before even reaching the target DNS server.

To mitigate this, you can encrypt DNS queries using DNS Over TLS/HTTPS or use Tor or VPN. Note that if you don't set up your VPN correctly you might leak your DNS queries.


Unless there is a configuration issue or a specific vulnerability, the root directory will be /var/www. That means that anything you upload will be within that directory.


Why does an RSA key (256 bits) have more than 256 bits of ascii characters?

The PuTTY format for an RSA SSH2 private key blob is dlen||d||plen||p||qlen||q||ulen||iqmp. The values dlen, plen, qlen, and ulen are the length in bytes of d, p, q, and iqmp, respectively; the length is expressed as an int, so each of the four length markers itself takes up 4 bytes. The four key elements stored are respectively the decryption key d, the prime factors p and q, and the value of q^(-1) mod p -- the last 3 aren't technically needed, but they significantly speed up RSA operations.

In your key, d is 256 bits (32 bytes), p and q are each 17 bytes, and iqmp is also 17 bytes. The 17 byte lengths of p, q, and iqmp are artifacts of the somewhat odd rounding method used; to compute bitlen(p)/8 rounded up to the nearest byte, the PuTTY source computes (bitlen(p)+8)/8. If p is exactly 128 bits long, then (128+8)/8=17 is the value of plen, even though p fits just fine into 16 bytes. Likewise for q and iqmp - the values are all actually 128 bits exactly, but the odd rounding turns them into 17-byte values. There's no security consequence either way, as far as I know; it would have made more sense to add 7 bits and integer divide by 8, but they made it the way they made it, and can't change it now.

Anyway, that's the components of the blob: 4 bytes for dlen, 32 for d, 4 for plen, 17 for p, 4 for qlen, 17 for q, 4 for ulen, 17 for iqmp. Add them up, you get 99 bytes, or 792 bits. For convenience, this is then encoded with Base64, which uses a subset of 64 characters that are particularly "safe" -- "safe" here meaning that they can be processed using systems designed to process text (notably email) without any major issues -- no trouble with special characters, no trouble with programs that only support ASCII characters and don't preserve the 8th bit of the byte, etc. That's how the message goes from 792 bits to 132 characters.


Difference between password expiration and account expiration

I think password expiration and account expiration are two differents means to achieve the same goal, that is to prevent someone to log in. However, they are used in different context and for different needs.

Password expiration is used when you want to force someone to renew their password at a specific interval (maybe 90 days) but you want the account to stay enabled. The user will be prompted to change his password and the next logon.

Account expiration should be used in another context. For example if you hire a contractor for 6 months and you want the account to be disabled at the end of the contract, you can set an account expiration at a fixed date and you won't have to be concerned about removing access to this contractor when the contract is finished since the account will be automatically disabled.


How to force ALL programs to use my Proxy?

Have you considered using a transparent proxy?  It can automatically intercept all traffic and feed it to the proxy.

If you're asking about Tor, check out the Tor transparent proxy, which might do exactly what you want.  You might also check out Torouter.


Received a mail that my password for an app has been reset. Does this mean my GMail is compromised?

Now this means only one thing, that someone had access to my email(Gmail) account.

I disagree with this statement. You are jumping to conclusions. I'd like to point out other possibilities.

They are taking pre-emptive actions to reset passwords. For example, if they know they have been breached, or they decided to look into the massive database of leaked password that has been circulating since December to see which of their user was affected.

For example in December Wordpress.com did that. They sent out emails with the title "Your Wordpress.com password has been reset". But they started their email with: "We recently discovered your login credentials in a list of compromised emails and passwords published by a group of security researchers.", and explained the situation.

Someone might have managed to convince Zoho to reset your password, pretending to be you and having lost access to your email account. In this case they could have bypassed the sending of the first email step altogether. Your Gmail account would not need to be compromised. This is highly speculative - someone would need a real good reason to go through all that trouble - but nevertheless a possibility.
It can be a mistake! A support tech miss-clicked and reset the wrong account's password. A developer wrote a buggy piece of code that found its way to production. Things like that happen...

Read carefully the content of the email, does it mention anything about why the password has been reset? Are you sure it comes from Zoho? Then contact them and ask what's going on.


There's no way to give you a probability for every program, but I can say that no it is not safe to run a fuzzer on a program with access to a filesystem that you do not want damaged. While programs that do not do any I/O at all are much less likely to delete or modify files, it is still absolutely possible. I have had data on filesystems damaged (and in one case, the filesystem itself got corrupted) as a result of fuzzing with AFL. Thankfully in my case, the program only had access to an empty partition...


In HTTPS, the TLS channel is established before and HTTP data is transfered so, from that point of view, there is no difference between GET and POST requests (or any other HTTP verb, for that matter).

A few things might impact system security, though:

GET requests usually are logged in full while POST requests usually are not. This means that, potentially, you might get more information leaked through GET than POSTS (this logging can happen in the client - through history - on a proxy server or on the web server itself).
GET requests are more constrained by size than POSTs. This makes it (slightly) more difficult to use them as a way to attack the web application.


Preventing CSRF with SameSite="strict" without degrading user experience?

Short answer: No, there's no way to have the benefit of Strict SameSite without the drawbacks of Strict SameSite. However, you can get most of the benefits (and fewer drawbacks) by using Lax SameSite.

I think you quite badly misread that article you linked. Google is not, and has no plans to, change the default SameSite behavior to Strict. All they are doing is changing the default to "Lax" and adding "None" as a new option to override this default. ASP.NET is making no changes except adding the None to the enum values.

The concern is that, if you send SameSite=None to a browser that doesn't yet know about this value, it will interpret it as SameSite=Strict because that's what the standard says to do when the value isn't recognized. Therefore, IF and ONLY IF you DON'T want to use SameSite at all, you will need to do user-agent sniffing to determine "this browser still defaults to no SameSite and will freak if I say SameSite=None" vs. "this browser defaults to lax SameSite and I need to tell it to not do that".

If you expect top-level navigation from other sites to yours, but do not expect to need cross-site authenticated requests other than top-level GET navigation, then you should already be setting SameSite=Lax, and this change (neither Google's change nor ASP.NET's change) has no impact on you.

If you are already using Lax SameSite, you literally don't need to do anything at all (I guess you could save a few bytes by sniffing new Chrome builds and not sending the now-redundant header, but it's probably not worth the effort).

If you actually want to use Strict SameSite, do it exactly the way you would today; nothing has changed there either.

As a final word of advice, bear in mind that there are still a lot of people using outdated browsers that don't support SameSite at all. It's potentially valuable as a defense-in-depth measure against CSRF, the same way CSP is a defense-in-depth against XSS, but you still need some other anti-CSRF mechanism for anybody on browsers that don't support SameSite, unless you block all such browsers from signing in at all.


It depends.

Save it on someone else's server (Dropbox, Google Drive, etc.) if you want convenience at the expense of security

And the first time you accidentally type your KeePass password into your Dropbox/Google Drive login, you just gave that someone else the keys to open up your password vault.

Save it on your own machines, set up so they aren't backed up to someone else's server (i.e. the cloud), and sync the various KeePass files as you need.
Save it on your own encrypted machines, on encrypted storage - perhaps LUKS (built into Linux) or Veracrypt, or an Apricorn FIPS 140-2 validated USB drive, or a combination.
Save it on your own guaranteed offline, isolated machine/storage

For more details on more secure - and less convenient - isolation, see this answer


Difference between AES-128 CMAC & AES-128 ECB/CBC?

Shortest possible explanations:

Confidentiality -- no adversary can learn the content of the encrypted message

Authenticity -- any attempt to tamper with the data will be detected

These two notions are independent, e.g. one-time pad provides perfect confidentiality but no authenticity (adversary can flip a bit of the ciphertext in transit and this will result in a flipped bit of the decrypted message).

Now, to provide confidentiality we use ciphers. To provide authenticity, we often employ MACs i.e. Message Authentication Codes.

MAC algorithms can be constructed using block ciphers. CMAC is an algorithm that uses a block cipher as a building block of the MAC. Depending on the underlying block cipher we talk about AES-128 CMAC when the cipher is AES with 128 bit key or e.g. Serpent-128 CMAC if the block cipher is Serpent.

CBC or ECB are modes of operation of a block cipher. Mode of operation is used to provide a way of encrypting arbitrary amount of data with a block cipher that by itself can encrypt only fixed block of data (e.g. 128-bits in case of AES). If you have anything else than 128 bits, you need to use a mode of operation.


While other answers state that it makes sense for the malware authors to deliver on their promise to decrypt your files (I agree, it does) they offer no evidence. Anecdotal evidence is the best you'll get in the case, but it is not unheard of that the criminals will actually decrypt your files for you.

This New York Times article details how the author's mother's computer became infected with ransomware. Here are some selected sections to answer your question:

  Of course, this advice arrives too late for my mom. And it appeared her payment had arrived too late as well: By the time I got home from Greenpoint, her CryptoWall ransom had been raised to $1,000, and the $500 in Bitcoins she had deposited had vanished. In a panic, she wrote to Mike Hoats asking for advice. What he told her sounded crazy to me. Use the CryptoWall message interface to tell the criminals exactly what happened. Be honest, in other words.

  So she did. She explained that the virus had struck the same week that
  a major snowstorm hit Massachusetts and the Thanksgiving holiday shut
  down the banks. She told them about the unexpected Bitcoin shortfall
  and about dispatching her daughter to the Coin Cafe A.T.M. at the 11th
  hour. She swore she had really, really tried not to miss their
  deadline. And then a weird thing happened: Her decryption key arrived.

  But Mr. Wisniewski had a more pragmatic take. “From what we can tell,
  they almost always honor what they say because they want word to get
  around that they’re trustworthy criminals who’ll give you your files
  back.”

  Welcome to the new ransomware economy, where hackers have a reputation
  to consider.

Additionally Dark Reading cites two additional cases of police departments paying the ransom, and getting their files back.

However keep in mind, there are many types of ransomware written by many different programmers with varying level of skill. Some will simply not give you a decryption key, and I image some botch their whole malware and can't offer decryption keys. Other cases have been known in which the decryption key is stored on the victims computer, and you can recover your files without paying anything(example).


Can an SSL cert/key pair indicate that they need an intermediate

X.509 certificates include a pointer to the authority that they fall under. That can include an intermediate certificate. This means you may need to install a copy of that certificate locally. Consider this article.


Security implications of hostname identification in SNI and other SNI questions

I believe that before SNI, there was nothing in an SSL/TLS packet itself that could identify the site somebody was trying to hit.

That's wrong. The certificate sent back by the server contains the site name as the subject. Although this is maybe not as specific as SNI since there might be multiple names given as subject (especially true with CDN).

  If I install a non-SNI certificate ...

There is no such thing as a SNI or non-SNI certificate. SNI is an extension in the TLS handshake which is needed to support several sites and thus different certificates using the same IP address. It is comparable to the Host header in the HTTP request. And because SNI is used by the client to actually get the  certificate matching the target name in the first case it cannot be a property of the certificate.

It is fully up to the client if the SNI extension is used or not. But, all modern browsers and most TLS libraries do it because they need to support the common case of multiple sites sharing the same IP address.


Do long password actually help protect your accounts on websites attacks

There are two parts to your concern about password length, the threat model and the rationale behind longer passwords.  As you state,  a lot of websites have protections against common attacks, and if the password database hasn't been leaked, your password isn't easily guessable, and online protections against brute-force protections are in place, longer passwords don't make much of a difference.  When those assumptions fail, long passwords can make sure your password is too expensive to crack, as demonstrated in research.  The more general case of this question, "Why have strong passwords at all?", is covered in this question.

Threat Model

The threat most password policies are concerned with is an attacker trying to crack the hash of the password which has been stolen or leaked from the system, also known as an offline attack.  This usually has some of the strictest requirements. However, these offline attacks aren't the only threat model.  You password could be compromised in other ways, like:

Brute-force on the website itself, as you mentioned:  Most secure websites have protections against this, which are further discussed below. Long passwords do help you from online brute-force attacks, although the cost/attempt is much higher than an offline password cracker.  These kind of attacks are somewhat common.
You reused a password and the password was compromised elsewhere:  The only prevention here is to not reuse passwords. Password length won't help here and too stringent of password requirements might even discourage users from setting a different password for each site.
A friend, colleague, or social engineer is trying to guess your password based on their knowledge of you: While password length helps here, you don't need very long passwords to stop this attack, and often services are rate limited to only a few attempts per hour per computer.
There are also methods like phishing, exploiting the password reset, and stealing a plaintext database. In all of those threats it doesn't matter how complicated your password is; it's gone anyways.

Focusing just on online attacks and limiting log-in attempts is bad practice because password database leaks do happen.  LinkedIn, MySpace, Adobe, Dropbox, and others have all had password hashes stolen. You can check if you appear on any public leaks here.

Don't Websites Block Online Brute-Force Attempts?

A major part of your question appears to be why password requirements are such a big deal if protections against brute-force attacks are in place.  PCI compliance, for example, requires account lock-out for at least 30 minutes after 6 failed attempts. The biggest problem in preventing these attacks is working against botnets with thousands of computers without causing a denial of service.  How do you prevent thousands of computers each trying to log in a few times without also locking out the user when they mistype their password while using a new computer, or using the same proxy as the botnet?

There are other ways other than lockouts to rate-limit attackers, like asking for CAPTCHA. However, there are some ways to work around CAPTCHA.  This OWASP page discusses more of the best ways to block brute-force attacks.

Why Longer Passwords Help

A few decades ago when Unix was king, it was considered that five-character passwords were pretty good.  Now the stakes are higher, advanced hardware is cheap, and hashes can be broken faster than ever so the requirements for good passwords are higher.  This is part of the reason more companies are pushing for longer passwords.

Longer passwords help because the difficulty of password cracking goes up exponentially with password complexity.  Just adding one random word to your password can make it thousands of times more expensive to guess- the difference between seconds and hours of cracking time.  Adding another random word turns those hours into years.

Many people advocate for using symbols and creating passwords from larger and larger character sets to make passwords more difficult to crack.  However, several examples in research show that requiring longer passwords instead of very complex passwords leads to harder-to-crack passwords (and is more user friendly).  The longer passwords side was also famously supported by xkcd's "correct horse" method to generate passwords.

One caveat is that longer passwords aren't always more secure since extra characters can make a password more predictable.  "orrect horse battery staple" is more secure than "correct horse battery staple", although the latter is much more memorable.  Good password meters like Telepathwords or zxcvbn take this into account and will warn you when the extra characters are predictable.

How Long Should Passwords Be?

The specifics of how long your password has to be, and how hard it is to crack, can't be answered without knowing how your password is generated, how the password is hashed on the server, and the attacker's resources. For more details see this question.

I'll warn you, that password policy is a matter of opinion.  I've tried to show the best solution based on research, but there are some experts who disagree with me.


AWS serverless site security. Anything else I should add?

I have a question is it not possible to spoof here, I am assuming I get to the landing page once I get the ip right?

Then we have the hardcoded password which I am not a fan of.

https://www.owasp.org/index.php/Use_of_hard-coded_password

These are the ones in correlation to your statement I would suggest you go through

https://www.cloudconformity.com/knowledge-base/aws/CloudFront/

These are places to start I guess, also
I am Sorry for the formatting issues I have not gotten used to the mobile version.


Is a company responsible for a spam which mentions it?

This largely depends on the legal system in the country the complaint is filed, so the usual IANAL disclaimer applies. In general this kind of thing is an investigative matter. If the company's site is mentioned in spam, an investigator will assume that the site is involved or responsible. Further investigation will likely involve looking for money trails to known spammers, rogue advertising networks, malware factories, etc. However, if a jury can be convinced that the company was aware of and directly involved in the spam, it may be possible to convict them under a conspiracy charge.


The main things to be mindful of:
 - If you mount full directories, you effectively give chrooted user access to all those resources (most notably binaries). It would be more secure to only put required binaries into chroot (i.e. in one case I had to provide access to ls and scp only, but nothing else). This will potentially limit attack surface, as there would be fewer executables to exploit.
 - On the other hand, mounting those directories allows to keep chrooted resources up to date, potentially limiting explotable vulnerabilities. But this can be achieved by updating chrooted resources manually or via scheduled script.

Overall, keeping chrooted environment fully separate is considered more secure. But it all ultimately depends on your level of paranoia, criticality of this system and other security controls you might have in place.


Are OBD-II "Connected Car" products (Automatic Pro, Hum) secure?

Are these devices actually safe to use?

No. These devices have access to the "low speed CAN bus" and actually send out messages on the CAN-BUS. Anyone compromising your OBD-II device can send out fake messages to trick different ECU's attached to the CAN bus.

  Are manufacturers taking the potential compromise of these units seriously?

Yes, but there are a few issues. Although the big manufacturers understand that there is a potential security risk, there is not much they can do about it, due to  the inherent limitations of the CAN bus protocol.

In order for them to implement security without changing the CAN bus protocol the correct way would be one of the following:

Manufacture each ECU with a AV in the ECU from the beginning (already being done by Karamba Security)
Have another ECU connected to the CAN bus listening and performing DPI (being done by Argus Sec)
Performing statistical analytics on the CAN bus behavior and being able to differentiate between normal activity and abnormal activity (being done by Cycuro)

So you are probably asking yourself, why you are not seeing any of this being implanted?

Manufacturing companies are scared to insert new devices onto the CAN bus without proper mass testing. In order for small companies to prove their product works they need to first test it on a massive amount of cars which is not available to them because the are manufacturers scared. So it's a whole loop.

Although this may be the case, there may also be a way out of this loop, as companies like Xee and Carvoyant are providing testing kits to be given out to drivers by developers. These dev-drivers have their data collected and sent to the developers "server", and at this point the data can be used offline/off-road to perform the necessary tests.

  Is such a thing even possible given the features they have?

As I mentioned above, currently that is not possible, due to the way the ODB-II protocol is set up.

Conclusion:

Manufacturers want to adopt cyber security prevention, but the market is not ready yet (but closer than ever!) and it is all up to you to make sure you secure the OBD-II enviorment with your awareness.

The attack vectors will just grow and attacks have the potential to start getting a little crazy (what about a mechanic's computer being compromised and then used to spread malware to cars through the mechanic's OBD-II device?) and we need to wait and hope for the best from the manufacturers.

You can read more about the OBD-II and CAN bus here - CAN Bus and OBD II Explained For Dummies, with Examples of how CAN Bus and OBD II Work


This may be what you're looking for:

http://tinyradius.sourceforge.net/


Is loopback interface protected from sniffing?

If you can do it (with Wireshark or another tool), then any program that has the same privilege level as you can theoretically do it as well.

So if the question is: can the loopback interface be sniffed? I'd reply YES. From what I know, it's more or less the reason why it was created in the first place.


By default use AES. AES is a block cipher, i.e. a function which, given a key, maps block values (of 128 bits, in the case of AES) to other block values of the same size. To encrypt a message, one must use the block cipher in a chaining mode which tells how the input data should be split and encrypted and assembled again. Almost all modes allow for streaming (encrypting a huge message on the go, without having to store it entirely in RAM or disk). The good modes combine encryption and integrity check, see EAX and GCM. Among traditional encryption-only modes, the current one is CBC, the newer being CTR; CTR has the advantage of not requiring padding, because it encrypts a sequence of x bytes into exactly x bytes, for all x, whereas CBC requires an input with a length multiple of the block size.

I have a 2.4 GHz Core2 Intel CPU on my PC. This is far from being the best available out there, and will soon verge on the "obsolete", at least commercially speaking. Nevertheless, when I run the OpenSSL benchmark tool:

$ openssl speed aes-128-cbc
(...)
type             16 bytes     64 bytes    256 bytes   1024 bytes   8192 bytes
aes-128 cbc     108028.29k   147211.99k   161986.82k   166308.90k   167286.10k

so the processor can encrypt data at the whooping speed of 167 MB per second; and that's using a single core. My PC has four cores, so even encrypting data at the maximum bandwidth which could go through gigabit Ethernet would use only 15% of the CPU resources. It would take a quite special application to actually make encryption a bottleneck.

Things will go even an order of magnitude faster on a newer x86 processor, one with the AES-NI instructions. These instructions allow for encrypting data at a rate of less than 2 clock cycles per data byte; if you prefer, it goes beyond the gigabyte per second. Note that this is about 10 times faster than what a typical harddisk can do. The AES-NI instructions also include the pclmulqdq opcode, which helps quite a lot when dealing with the GCM mode.

Nevertheless, there are conceivable, specialized situations where the raw speed of AES is not sufficient (involving machines which do not have AES-NI instructions, of course). For these, one could remark that a block cipher is a versatile primitive, and that maybe an algorithm designed specifically to encrypt long streams, but unable to do anything else, could possibly crunch data a bit more faster. These are called stream ciphers. An old, well-known, slightly weak and actually not that fast stream cipher is RC4. The eSTREAM project ran from 2004 to 2008 as a kind of open competition, with stream cipher candidates and open comments and workshops, and resulted in a portfolio of stream ciphers which "look good" from both security and performance point of views (they did not receive at much scrutiny than AES, but they got a fair share nonetheless). There are four ciphers optimized for software platforms, and three for hardware designs. They are all unpatented and free for any use (Rabbit was patent pending, but in October 2008 it was released to public domain).

An example of application where a stream cipher gives an edge over a block cipher is actually not security related: this is heavy numeric simulation, which requires a steady stream of random values of high quality. Stream ciphers produce high-quality randomness (they are designed so that no bias can be found, even by looking for them on purpose, whereas custom non-cryptographic random number generators tend to rely on luck -- that the problem at hand does not happen to hit one of the known biases of the RNG). For such a purpose, I have successfully used Sosemanuk, one of the eSTREAM portfolio stream ciphers.

Either way, block ciphers and stream ciphers both need proper IV management. The IV is a parameter which needs not be secret, but which must have some specific properties. For some ciphers, it suffices that no two messages are ever encrypted with the same key and the same IV. Some others (including CBC mode) require a bit more, namely that the IV is chosen for each message with uniform probability among the space of possible IV. Anyway, the IV must be known by the receiver, so it is customary to send it in the header of the encrypted message. The RC4 stream cipher has no IV: a given key must never be used for more than one message. IV management is where you will have security issues, because it is often overlooked and not that easy to get right.

Summary: use AES with a proper encryption mode; you also need integrity checks, so a combined mode such as GCM is a good idea. Mind your IV. Envision switching to something else only if you find out that AES is an inevitable bottleneck, because there is very high probability that this will not turn out to be the case.


What are attackers trying to achieve when doing attacks on local programs such as buffer overflows?

An aspect which hasn't been mentioned yet very clearly: suppose you have a multi-user system (as all modern PC OSes like Windows, Linux, Unix and so on are), and suppose you are a normal (non-privileged) user who can run "normal" application programs. Now you want to do something malicious to your PC (like installing a keylogger to get all passwords which the other users of the PC are typing, or reading other users' emails). But you can't do that because you are just a normal user, do not have administrative rights, can't install software and can't view other users' data.

So your goal is to become a user with administrative rights (administrator in Windows, root in Linux / Unix, etc.). Besides tricking the administrator into giving you his password, another way to achieve that is to attack a vulnerable program which already is running with administrative rights. If you could make such a program run your code (for example, by abusing a buffer overflow), then this code would run with administrative privileges as well, and -bang- you could do anything what you like with the machine.

This is called privilege escalation. Please note that (due to technical reasons which can't be explained here in detail) practically every system has lots of (server) processes with root privileges running in the background, so this is a real scenario (actually, I am estimating that most of the attacks against local programs are done for privilege escalation).

So the key factor is: when you (a normal user) run a program, this program runs with your own privileges and access restrictions, but when you can make a program which is already running with administrative privileges run your own code by abusing buffer overflows and similar techniques, your code runs with administrative privileges as well.

Please note that this explanation is heavily simplified (for example, in Linux / Unix there are SUID programs and so on), but hopefully expresses the underlying idea.

One last thing: privilege escalation is often the goal whether or not the attack is done locally or remotely. Often enough, attacks work in two steps:

First, the attacker gets a naive user's password (for example, because it is too weak, is the birthday of his wife or the name of his dog)  and then uses these credentials to get onto the respective machine remotely.
Then, as the second step, being that user, the attacker scans the respective machine for vulnerable, privileged software and, for example by abusing buffer overflows in that software, lets that software run his malicious code which in turn is executed with the same privileges as the vulnerable software, effectively making the attacker an administrator.

Of course, there are also many cases where an attacker directly abuses privileged software running on a remote system (for example, web server processes running on Linux under root). But since you have primarily asked for the sense of local attacks, we'll leave that away for now.


Why do password strength requirements exist?

Because, as LinkedIn and other recent password leakages reveal, still the most common passwords for websites are "password", "god", "123456", etc. So you can brute-force with really short list of most common passwords. Still, you can just ban those passwords, or require long password - as possible combinations grow exponentially with the length, and requiring long password is better than requiring "strong" password to prevent brute-force. But too many people follow what they believe is a best practice without questioning it, so - great question indeed!


In an enterprise setting, it is always a good idea to segment the local network so that compromises in one area can't easily spread.

But a VPN solution is particularly tricky to secure since its whole purpose is to take computers outside your security boundary and let them tunnel inside. There is always going to be a risk that you need to be aware of and manage.

Ideally you would make sure that only legitimate devices and users can even get to the VPN end-point, using a non-standard port can be of some help it keeping "casual" botnets at bay. Some form of multi-factor authentication is really a must here.

Also ideally, the inner network that the VPN connects you to would also have limitations and you would certainly want further protected network segments for sensitive services such as your database servers.

For example, you might allow remote users access to some business services such as your Intranet but not others such as your Finance and HR services.

UPDATE: It is quite hard to explain the correct layout in just words. So please reference the SANS secure network design document from their reading room.


Start sending a simple PHP file with a command that does not require output, but allows you to determine whether it's been executed or not.

Simply run twice the RFI and send from netcat:

<?php /* do nothing */ ?>

and

<?php sleep(10); ?>

If the second command has the web site returning the page in a time 10 seconds longer than with the first attempt, then your RFI is potentially working. All that it can do still remains to be seen.

If the two commands return in the same time, there's no extra ten second pause, then the PHP code you sent is clearly not being executed, so sending a reverse shell makes little sense.

The next steps involve sending something that tries to show itself on the target page.

ob_end_clean();
print "OK";
die();

could work. Also, try to establish what system you're examining (e.g.: Ubuntu 12.04-LTS ). That will tell you what to pay attention to, e.g. AppArmor or SELinux or special permissions. Trying to get a phpinfo() would be good, to ascertain whether some functions have been disabled, for instance.

You work upwards from that to a full reverse shell. Along the way you'll probably discover why the reverse shell isn't working, and with some experience you should be able to get it working again, deploy something else, or conclude that there's no actual vulnerability.

One possibility worth considering would be to use the RFI to create a second RFI that's simpler to exploit, if the first attacked script is still capable of writing files to disk in accessible (and exploitable) locations.

But...

Notice that you included 'evilcode.txt' and the script requested 'evilcode.php.txt'. This is not a simple append (it would have been 'evilcode.txt.php').

What seems to be happening is that the page gets the basename of the file, then adds '.php.txt', which seems to indicate some plan at work. It's not .php, it's not .txt -- it's .php.txt, as if the author wanted to mark it as being PHP, but at the same time not PHP.

It's possible I'm reading too much in a simple extension. But it is also possible that the RFI, while being a remote file inclusion, does not execute the code straight away, but actually does something like:

// Load page from URL request
$code = file_get_contents($_GET['page']);
if (0 !== strpos($code, '<?php//SQUEAMISH OSSIFRAGE')) {
    // This is not our code! DANGER WILL ROBINSON!
    mailAdministratorAndRecordBreakinAttempt();
} else {
    // The code contains the secret word. It's legit.
    $result = eval($code);
}

The above would seem to be an exploitable RFI, but unless you happen to know the secret word, it simply won't work. On the other hand, you might be able to get it by reading one of the remote pages, now that you know how their
true local name is obtained.

This is hoping that those pages aren't IP-blocked, and requesting them from
anywhere else but server address doesn't result in an alert being triggered.


number of ciphertext-plaintext pairs needed in double encryption

At a minimum I can't see why you'd need more than one.

You're essentially just combining the key space by encrypting it twice with two keys.

You simply decrypt the cipher-text with every value in the K2 space, then decrypt every result with every value in the K1 space. When you find a match you have the correct K1 and a K2.