Do vendors put backdoors on network devices?

Are these backdoors real?

Yes, these backdoors are real. A quick search for vendor backdoor provides some examples:

Hardware Vendor Offers Backdoor with Every Product - that's about Allied Telesis  you've already mentioned.
Backdoor account replaced by another backdoor in vendor stumble - about a vendor backdoor in audio equipment, where the fix was to replace the backdoor with a new one.
Equipment Maker Caught Installing Backdoor Account in Control System Code - RuggedCom had a vendor backdoor in their industry equipement where the password could be derived from the MAC address.

And these are only some examples of obvious vendor backdoors instead of accidentally left backdoors from debugging or similar.

  Are they necessary?

These are backdoors the customers don't know about, i.e. the vendor can sneak in and make changes without the customer noticing. I believe that having such backdoors greatly undermines the trust into the vendor. I don't think these are necessary - there are ways to have service accounts which are known to the customer and get only enabled for a short time if the customer actually requests support.

  Is it also a potential danger?

Of course, For example in the above example of RuggedCom the password could be simply derived from the MAC address and not only the vendor but also potential hackers had knowledge about it. This means it is no longer a vendor backdoor but a backdoor for hackers too.


Are "web bugs" a technique that instructs web browsers to operate the computer's microphone?

With the added context to the 2011 Berkeley exam answer sheet passed in your comments section the answer is indeed false.  They were looking for the Wikipedia definition of "Web Bug". http://en.wikipedia.org/wiki/Web_bug


Pros/Cons for showing a user how many failed login attempts they have remaining before getting blocked?

This looks like my bank. If I mistype the password, they warn me that my card will be blocked if I don't get it correct in the next 2 trials. And that increases my stress. I don't like that message.
I would not add that kind of message because it does not helps the user remember its password. If the user mistyped the password, they will hopefully get it correct on the next try, and if they forgot it they will get it wrong again on the next try.
For an attacker, it won't change much. Assuming they can create a user on your site, they can test themselves how many passwords they can try until they get blocked.


Yes, Java class files are easy to reverse engineer. The format is very regular, and very constrained: the VM must be able to verify that the code complies to the strong typing rules of Java code. This is like the output of a C compiler with all optimizations deactivated: the program structure is plainly visible. (In the Java model, optimization happens in the VM itself, when the JIT compiler runs.)

People try obfuscation, though; e.g. with ProGuard (there are many tools on that market; this one is free and opensource). For instance, all classes and methods are renamed with strings which make no sense to a human (but the obfuscation also produces a translation file which the developer keeps for himself, so that he may interpret back stack traces in case of bug reports).

Alternatively, you might be able for process your Java code in an Ahead-of-Time compiler, like JET. This has some restrictions (in particular, the result is no longer "portable" since it is native code) but it makes decompilation harder (close to the complexity of reverse engineering compiled C or C++).

As a rule, reverse engineering tends to work, and for Java even more so, even after obfuscation. You'd better not use obfuscation as the foundation of your security.

It is also worth noting that this is very similar to code reading issues in any .Net language such as C#.  It is pretty much equally trivial to generate Java, VB.Net or C# code from the distributed files and obfuscation techniques that try to make it more difficult to read are similar for both as well.


What skills will I need to learn for a 'Security Analyst' job role?

The exact details of a particular analyst position are going to vary from job req to job req. The best thing you can do is look at what various positions are requiring as background knowledge and become proficient in these functional areas.

To get you started, here is a job for one of our analyst positions, I think it's a good primer to get you started.

  Demonstrable Skills and Capabilities

  Strong interpersonal, organizational, communication, and writing
  skills

  Being an Analyst means engaging with clients; meeting their
  objectives and communicating the details associated with potential
  threats is critical to success. You must be the expert in the room,
  and able to communicate and support your recommendations.

  Independent investigative skills

  The Analyst must be able to make sense of the
  technical information at their disposal. This includes the capability
  to investigate technical elements they might never have seen before.
  While senior personnel are available to provide assistance it's up to
  the Analyst to investigate the issue prior to escalation.

  Required Technical Skills

  Working knowledge of the TCP/IP suite of protocols
  Conceptual
  knowledge of network and systems architecture
  Network segmentation
  (e.g., DMZ)
  Intrusion Detection Systems
  Web application architecture
  Active Directory Solid understanding of how major application layer
  protocols function (e.g., HTTP, SMTP, DNS)
  Basic knowledge of categories of malware and how they function (e.g., rootkits, trojans, adware)
  Conceptual understanding of vulnerabilities and attack vectors
  such as: SQL Injection Brute force attacks Portscans Malware infection
  vectors Phishing attacks Driveby/Redirection attacks

  Optional Skills

  Certifications are always a plus, but not required:

  CISSP
  GCIH
  GCIA
  GSEC

  Programming/Scripting (e.g., Perl, Python, Ruby) Network traffic
  analysis skills Comfortable in multiple operating systems (Windows,
  Linux, Unix, OSX)


How to store passwords written on a physical notebook?

In approximate order of increasing complexity (not security, and methods may be combined), here are some ideas that would be easy for anyone used to puzzles/writing code/maths.  A more complete idea is below.  NB: when I say "secret" I mean not written in the book. These are all easy, and most useful to deter the casual thief.

Have a memorised secret element, common to all passwords. *
Minor variant -- an secret element easily derived from the website name/username.
Put too much information in the book, e.g. know that actually you omit the first 4 characters of each password.*
Offset the account and password by some constant number of entries. *
Never write the full username, just enough to be a clue to you.

* These items have the significant vulnerability that once the obfuscation is cracked for one entry, it's automatically cracked for all entries with no further effort.

If the exact algorithm is published, clearly a notebook-thief who could also script login attempts (or a team of course) could apply the algorithm automagically -- or all published algorithms.  The type of algorithm could be published, for example:

From the password as written, call the first digit x and the second y.
Count x characters from the first punctuation mark (or first character, or first digit).
Then swap the cases of the next y letters (or preceeding y) letters.
For a memorised 4-digit PIN, increment the first four letters by the numbers of the pin (e.g. 1234 applied to a!bcd would give b!dfh).

Of course you could:

Swap the meanings of x and y
Increment/decrement x and y.
Count from the first vowel.
Swap the cases of y consonants.
Replace digits with their corresponding letters by alphabetic position and vice versa.
Swap digits for the punctuation on the same key (you either need to be confident in the keyboard layout you'll encounter or know your own keyboard very well.)

All these operations, by definition, can be scripted.  But the notebook thief would have to get hold of (or write) a script implementing these (and it's actually quite a variable space even without a secret element.  Then they'd have to type in the passwords (an error-prone process with randomly-generated text), run the script over the list, and attempt to log in with the now potentially thousands of passwords per site.  And hope that the site doesn't lock out after several failed attempts.

It would be worth keeping a backup list, even if not a backup copy of the book, as a list of sites for which the passwords should be changed/accounts flagged if the book went missing.

As with many security measures, the goal must be to make it too much effort to break in.  By combining manual and scripted effort you're doing quite a lot towards that, and increasing your chances that they'll give up.


New gTLDs are coming. How will browsers handle cookies, SOP and certificates?

SOP and wildcard certificates are orthogonal issues. SOP works on the names as found in URL, and don't care about what appeared in any certificate which may or may not have been involved at some point. If a script came from a URL in https://foo.example.com/ then https://bar.example.com/ will be considered as a distinct "origin", even if both use the same certificate with both foo.example.com and bar.example.com in it (or, equivalently, a wildcard name *.example.com).

Existing browsers use ill-documented restrictive rules on what wildcard names are allowed. See, for instance, this previous question. One frequent rule is that first-level and second-level wildcards are not allowed (so no *.com); new TLDs will not change anything to that. The tricky part is for "two-level" names which functionally act like TLDs, e.g. co.uk. The new TLDs are, for a large part, a way to avoid such two-level pseudo-TLDs, so it is expected that this will incur less trouble, not more.

All these games about wildcard certificates are only for SSL/TLS and have no impact at the HTTP level; SOP, cookies... don't care about wildcard names.

(Unless a browser vendor gets really creative, as they sometimes do.)


There are actually 3-4 questions in your post, and they can mostly be answered with just networking answers.

  if I spoof the "source" IP to an IP of the segment 172.16.x.x, will spoofing work?

It depends what you mean by "work", but the principle of spoofing is to fake packet and see what happens. You can fake what you want, the idea will be then to properly analyze how the network reacts and if there is any possible weakness in this reaction.

  Will injected packets reach to 172.16.x.x?

Possibly.

Normally, if properly configured when receiving a packet the layer-3 device connecting the two LANs should check if the source IP address is expected on this incoming interface.

Normally, and depending on the exact topology, it should detect that no packets with source IP 172.16.x.x should be received on the interface connected to the 172.13.0.0/16 network and react accordingly (drop the packet for instance).

However, this layer-3 device may be wrongly configured and could therefore allow such packets.

  Will I receive packets back?

By doing only what you describe, this one is a no for sure: the layer-3 device will have strictly no reason to route a packet with a destination IP 172.16.x.x to its 172.13.0.0/16 interface.

If you are required to be on the 172.16.0.0/16 network to reach the server, this would either mostly restrict you to UDP attacks (if the layer-3 device does not correctly check source IPs) or find a way to convince the device that you are a legitimate route toward other hosts belonging to the 172.16.0.0/16 network (which would very heavily depend on the exact network devices and configuration, but for instance facing poorly managed switches you can try to exploit some layer-2 attack and jump onto the VLAN associated to the 172.16.0.0/16 network).


How can I handle user authentication and sessions in my app?

The system you're describing sounds a lot like standard cookie based authentication/session management systems, in that you authenticate the user and then provide a session token to them which allows you to identify requests from that user for the duration of their session.

Whilst you could implement this manually, I would recommend against it, as there are quite a few potential pitfalls and things to know about getting session management correct and it would be easy to get it wrong and leave your application vulnerable to common session management attacks.

you haven't said what you're using to provide server-side logic for your application but for example if you're using something like Node.JS, then there are session management modules available in npm (for example Mozilla Client Sessions).

In general if you search for 'session management (your server-side framework)' I'd expect you'll find a number of modules which implement the needed functionality


Can Hydra and Crunch be used in combination for HTTP-get-form?

Short answer to your question is yes, Hydra and Crunch can be used in combination.

Your statement that "bruteforcing is generating every possible combination in order to guess..." is correct but the term "bruteforcing" is often used in relation to guessing based on a wordlist, so we just have to deal with the impercise term.

On to your goal of recovering your router username and password:

Try several different approaches, one being what you suggest, especially since you think you used a very easy to guess password:  Run Hydra against the http form with a short list of simple passwords, then a longer one, then employ Crunch.  The reason I suggest it is because you are likely to hit your password with one of the wordlists already supplied in Kali.

The other approach is attacking the router by other means besides Hydra as password guessing through a http form is very slow. It will be much faster if you can extract the hash of your password that is stored somewhere in your router and then run a hash cracker against it.  Since you don't have your password, I assume you can't just ssh into your router and look at the passwd file.  So, you will have to resort to researching router vulnerabilities and hoping that a vulnerability has been reported for your brand and version.  I would say that it is worth doing this while Hydra is doing its work.  Wifi Routers are famous for having unpatched vulnerabilities.

For example, read this:
 http://sijmen.ruwhof.net/weblog/268-password-hash-disclosure-in-linksys-smart-wifi-routers

What brand of router are you attacking? Does it have the OEM firmware installed?


What might be the legal and policy consequences of traffic sniffing?

I'll start with the usual statements that I am not a lawyer and this is not legal advice :)

That said as far as I'm aware use of a Network sniffer, in and of itself, isn't illegal in the UK (a large number of IT professionals would be in deep trouble if it were!).

If there is relevant legislation i'd think it'd be the Computer Misuse Act, the Regulation of Investigatory Powers Act and/or the Data Protection Act.

If you've intercepted and viewed traffic belonging to other people, that could be a problem, but if you installed it on your own PC and the target network is running a standard switched environment, then I wouldn't have thought it likely that you'd have had access to other users traffic, so effectively all you've done is view your own information.

The company could be considered to be in breach of the Data Protection Act, if they're sending personally identifiable data over an untrusted network (eg, the Internet) without appropriate protection (eg, SSL)

However unless you were authorised, you could be in breach of the IT Policy of the company, which you may have been given and asked to sign when you joined (I'm assuming here that you're an employee of the company) if you used unauthorised software within their network

as @Iszi said if you're concerned that they may actually charge you, I'd thoroughly recommend speaking to a lawyer.


How to test the php vulnerability CVE-2014-3515

Stefan Esser actually wrote a proof of concept for this vulnerability. You can find the entire post here. I will not reproduce the code here because it's super long, but the general gist of it is this:

Spray the heap with a repeated pattern of fake hashtables, buckets and zvals
Trigger the malicious unserialize().
Program segfaults
Picking through the coredump reveals that you control the Return Instruction Pointer, and therefore have pwned the machine very, very hard.

This POC was developed for a Mac OSX system running PHP 5.4.24, so it may or may not work against a Linux system.


Recover GPG private key from known encrypted file content?

I’m sorry for you but no, you cannot.

Your public key is (meant to be) public, so anyone should be able to generate thousands of files encrypted for your private key. If it were possible to deduce the private key from matching cleartext and encrypted file, then the encryption scheme would be (very) weak.


Does setting a user password on Windows XP help protect against remote exploits compared to no password?

No, there is no additional protection against remote exploits, but you should always set an account password wherever humanly possible, for a whole host of reasons not related to remote code execution bugs.

Remote exploits usually result in code execution, and that code would run under the privilege level of the user that was running the exploited service or application. As such, the password mechanism is entirely bypassed.

This is especially the case for services running under dedicated service accounts, such as NETWORK SERVICE, LOCAL SERVICE, or SYSTEM, which don't technically have passwords in the first place - they have NTLM hashes with random values, and login is disabled for them.

The only protection I can see is in a scenario where a low-privilege user (e.g. a limited or guest account) runs an application that is open to the network, and that application is exploited. From there, a passwordless account is a target for horizontal privilege escalation, or vertical privilege escalation if the account runs as administrator.

All in all, I would suggest that a password is always set on all user accounts, but not for remote exploitation protection reasons. There are so many other reasons to set a password.


iPad infected with virus (popup - admobinew.com)

At the moment it looks like it's a form of malicious advertising for all kinds of things.

Yes, more than likely these are on the sites themselves and not on your iPad. Close all browser tabs and try browsing sites without popup advertising. E.g. google.com and bbc.co.uk (no adverts when accessed from UK however I believe they carry non-intrusive ads for foreign visitors). If these warnings don't popup on known "safe from bad ad" sites then it is more than likely scareware ran by advertisers on the sites you visit.

If the popups are still happening then it could be your local network or ISP. Try against a trusted HTTPS site and also from a different Wifi network.


How to overcome slow process of creating and verifying digital signature?

The process of generation and verification of digital signature requires considerable amount of time.

I doubt this claim:

Currently used cryptographic hashes are designed to be fast.
Data can be feed into the hash in pieces: one does not need to keep all the data to be signed in memory but can feed the data into the hash piece by piece for example while doing other kind of processing with the data which are usually more expensive than the hashing (like streaming on a network, copying it, transforming it for transport...).
Hashing does not need much memory, i.e. it only needs a constant amount of memory no matter how much data you include the hash.
The final signature only involves (more expensive) cryptographic operations over the small hash no matter how much data need to be signed and is thus fast too.

  So, for frequent exchange of messages the speed of communication will reduce.

The only kind of expensive step is creating the final signature using the private key, the hashing itself is cheap. Still lots of signatures can be created in a short time with common hardware and if this is needed the other processing during communication (i.e. transport over network) is probably more significant for performance  than the signing process. For example each full TLS handshake (i.e. HTTPS) is creating and validating digital signatures and still the performance of the connection is bound primarily by the latency of the network and also the key exchange, but not by creating or validating digital signatures.

It can be expensive though if lots of small data need to be signed - in this case aggregating the data and signing together might be done depending on the use case.

And it can be slow if slow hardware is used, like for example smartcards protecting the private key. In this case the hashing is usually done outside this hardware and the slow hardware is only used for the ultimate signing of the small hash. When using a smartcard for signing a high performance is usually not required. The user has to put the smartcard first into the smartcard reader anyway and maybe unlock it with a PIN so the additional slowness of the smartcard is not that relevant compared to the slowness of this whole process.

  And noticed there are commercial digital signature providers ... How they overcome the slow process of verifying digital signature?

The site you reference does not do any digital signing at all. They do offer certificates which can be used for digital signing though - nothing special and not different to what others offer. The signing is still done by the user itself by using the (secret) private key owned by the user.


"Spoofing" in the context of networking means that you create communication in a network system which appears to originate from another host. In order to do this successfully, you need to impersonate them on every protocol layer of the application you want to impersonate them on.

Just injecting IP packets which seems to originate from another host is insufficient to impersonate that host during a TCP connection, because every TCP segment has a 32bit sequence number. A segment with a sequence number which is out of line will be ignored. That means in order to successfully insert a TCP segment into an existing transmission you need to guess the next sequence number, or your segment will be discarded. This isn't so hard when you can eavesdrop at least on the client, but when you can't, you can only brute-force it. With more simple transport protocols, like UDP for example, you don't have that problem. UDP has no sequence numbers, so unless an upper protocol layer replicates such functionality, you can just insert additional segments which will then be treated as if they were coming from the real host.

You also have another problem when you have no existing connection and instead want to establish a new TCP connection which appears to originate from another host. In order to establish a TCP connection, a 3-way handshake is required. (client sends SYN, server sends SYN,ACK, client sends ACK). The SYN,ACK by the server includes a random number which you need for an acceptable ACK. So when you can only send IP packets but not receive any of the packets intended for the spoofed host, you will have to guess this number.


Is cloud hosting allowed for FIPS 140-2?

(Disclaimer: I am not a lawyer; don't try this at home.)

The U.S. government does have very specific guidelines for government agencies wanting to consume cloud services. Those cloud services must be FedRAMP certified. This is an arduous, lengthy, expensive process... and it's specifically geared toward cloud services, not managed or shared hosting.

  Per the OMB memo published on December 8, 2011, all low and moderate impact cloud services leveraged by more than one office or agency must comply with FedRAMP requirements by 2014.

FedRAMP prescribes a bunch of security controls and configuration baselines here.

FIPS (140 and otherwise) and FedRAMP are not the same thing. FIPS 140 is much more specific, and details requirements for the use of cryptographic modules, which symmetric algorithms are allowed, which hashing algorithms are allowed, etc. Using another vendor's cryptographic modules in a FIPS-compliant manner is not the same as having a FIPS certified solution. FIPS certification (The Cryptographic Module Validation Program) is also a lengthy and very expensive process whereby you must submit your cryptographic module (be it a physical hardware security module, or a software module such as a DLL file) to the government for them to review it and approve it. A cryptographic module can not be FIPS certified, even if it generates identical data as a FIPS certified module, unless it has passed the CMVP. However, you can use and incorporate other vendor's modules (such as OpenSSL, bcrypt.dll from Microsoft, etc.,) in your solution and still call it a FIPS compliant solution, or that it is operating in a FIPS compliant mode.

FedRAMP is about certifying your entire cloud solution, which is much grander in scope than just one application. FedRAMP encompasses everything from the physical security in your datacenters, to your disaster recovery plan, to how well documented your solution is, to how you conduct regular vulnerability scanning, as well as inspecting every operating system, application and server in your environment.

If you look into the security controls set forth in the FedRAMP certification program, it does mention FIPS several times. Cryptography must be employed in a FIPS-compliant manner throughout a FedRAMP-certifiable solution.

  Is it okay to host your FIPS level 1 compliant application in the cloud? How about level 2?

Yes it's OK. FIPS is always OK (and furthermore typically required) for U.S. government agencies. In my experience, FedRAMP is not very picky about FIPS Level 1 versus Level 2, etc., only that FIPS Level-something is being used wherever cryptography is used.

If your solution is all software, I think the best you are going to do is FIPS 140 Level 1, since the requirements for Level 2 and above call for physical tamper proofing, tamper evidence and other physical security measures (like that PCB coating you mentioned,) and a purely software solution can never meet those requirements. A module that is validated to level 2 or above would be something like a smart card or hardware security module that has physical attributes.

  If #1 is yes, are there specific requirements/certifications needed by the cloud host?

FedRAMP, and possibly others such as FISMA depending on which government agencies are looking to buy service from you.

  Just want to validate my assumption: it is okay to collocate at a normal facility for level 1, correct? If not, what are the requirements/certifications needed by the host? What about level 2?

There is no clause in any of the baselines that expressly forbids colocation and shared hosting, however, it's been my experience that you will need to show strong evidence of role-based access controls and sensitive accounts management, specifically when it comes to being able to disallow non-U.S. citizens from accessing the system, or even preventing U.S. citizens who are travelling abroad from accessing the system. This will probably implicitly disqualify most instances of colocation because I couldn't guarantee that the datacenter cage next to yours couldn't be rented out by Russian spies, etc.


No.

Prevention of Cross Site Scripting, SQL Injections and the like are implementation details. They depend on the care and expertise that the developers put into the code, and no library can solve this for you. There is a broad spectrum of utility libraries available that can help you with this task. Trying to create a comprehensive list would be beyond this answer.

Trusting automatic mechanism, especially a single library to blanket-solve mentioned security issues, is a breeding ground for security vulnerabilities. There is no way around the fact that securing a system costs time, energy and resources. A better understanding of the nature of these vulnerabilities might be the first thing necessary to prevent the same.


GnuPG / OpenPGP: How to eliminate redundancy in PGP private key?

OpenPGP is defined in RFC 4880, which probably is the specification you're looking for. OpenPGP files (no matter whether binary or ASCII-armored) are composed of individual packets, each having a header (that is probably what you have been observing regarding the "IQ").

In an OpenPGP secret key packet, quite a lot of meta data is stored. As it also contains the public key, expect the user ID packets to be included - if these are the same, there will be more redundancy.

For working out the parts not specific to RSA keys of given size, better work with binary files instead of ASCII-armored ones (you're closer to the values given in the specifications). Very helpful at dissecting OpenPGP files will be gpg --list-packets, which dumps the contents of each packet in a more human-readable version, but also gives you packet identifiers and similar data you can look for in a hex editor.


Restarting nginx with Jenkins or Phing - is it safe to allow Jenkins to run sudo without prompt for password

The linked solution allows jenkins to run any command via sudo without a password.

A better solution is to allow jenkins to restart nginx without a password, but nothing else. This way you have root permission for the command you need to execute, but you're not granting blanket permission for jenkins to do anything and everything.

Use visudo to stick this at the bottom of your sudoers file:

Defaults:jenkins !requiretty,!lecture
jenkins ALL=NOPASSWD:/etc/init.d/nginx


how is Google Ads managing to track me? (even if I don't keep cookies!??)

I would try the following (while not logged in to any Google services of course):

Booting from a Ubuntu CD
Using a different device connected to your network (e.g. a smartphone or friends laptop).

If the ads change in both cases, it would suggest there is still something on your computer that is allowing Google to ID you. Perhaps an old installation of Google Talk? Maybe the cookies are (somehow) not being cleared?

If the ads remain the same in both cases, it would suggest that the ads are not tracking "you", but are perhaps based on IP address geolocation or some other indirect targeting method.

For extra points, you could check the IP geolocation theory further by booting from the Ubuntu CD again, and then borrowing your neighbors WiFi connection.

PS I would certainly expect different ads when using Tor - the exit node is likely to be in a different AS Number than your current IP, and that alone is very likely to produce a change in advertising.


Which Linux commands can execute user-supplied code?

What is it you're trying to protect against?  You sound like you're trying to protect against malicious users deliberately trying to gain further access to the system.

In that case, I'd suggest trying to find some other way for users to accomplish the same thing, without using sudo.  Well written suid scripts that accomplish the same thing, for instance.  sudo should be limited to users you trust, and users competent enough to understand Linux commands (more below).

You should also consider the case where the users are non-malicious, but have a deadly combination of incompetence, and over-confidence.  Several years ago I gave sudo access on a development server to a developer who was non-linux savy.  Within a week she completely destroyed the linux server environment with a find -exec command she found though googling how to fix her code. She didn't understand the implications of the find -exec command, and it completely changed all the permissions on the filesystem (including setting critical system binaries to non-executable).  I rebuilt the server, talked to her about the power of the find command, and removed her sudo access.

In both cases, you could likely still use whitelisting to give you some level of protection.  The problem with this approach is that raw linux commands run as root are extremely powerful, and it's difficult to anticipate all the ways either maliciousness or incompetence could bite you. Honestly, eliminating the need for sudo in the first place is still likely the best option.


Is it possible to find a zip password if it is being generated locally?

If a password is used, it must exist somewhere readable at some point in time. Whether or not the password is stored in obfuscated or encrypted form will determine what approach is needed in order to recover it. If it is simply stored as a string, hardcoded in the source, static analysis or even running strings on the program may reveal the password. Otherwise, you may need to do dynamic analysis (debugging or hooking functions; dumping memory perhaps) at the point of which the password is used.


There are several kinds of "secure":

If you want nobody near you sniff at your DNS traffic, then you can use a VPN to a trusted endpoint and then use the DNS server there.
If you want to serve your own DNS records in a safe way you can setup DNSSec, but beware that not all clients understand this (they usually fall back to insecure, but some might just fail).
If you want to be sure that you don't get spoofed DNS replies, you should setup your host to only do DNSSec queries and only accept DNSSec replies. Unfortunately a large part of the internet does not protect their domains with DNSSec yet, so you need to either accept insecure (and possible spoofed) replies or restrict yourself to the "safer" part of the internet.
It helps also to use only SSL (https) so that the host name in the certificate gets compared against the name in the URL and you get failures if somebody spoofed the DNS response. Of course this depends on the more or less broken PKI architecture of the internet (e.g. every CA can sign a certificate, no working revocation...).
Or do you want a DNS server which screens the replies so you get rudimentary malware protection. One example of this service is opendns.


What security risks does IP spoofing bring?

You are correct when you say an attacker spoofing IP may not receive traffic back, but they may not want to. They may want traffic sent to another IP address - possibly for denial of service attack on that IP.

Alternatively, there are attacks which just require the initial part of the handshake to take down your defences (you mentioned SYN flood)

Less of a direct risk, but also relevant is general traffic load. My take on this is to disallow as much as you can at the perimeter - this includes traffic types and ports you don't use, and also traffic which is effectively invalid. It is simple to do on most routers, and it means any deep inspection firewall has to trawl through less packets thus reducing the load.


explorer.exe outbound (Unexplained TCP Connections)

It is not normal for explorer.exe to reach out to the web. You should lookup the ips and see who owns them , what country they are located in, etc on arin.net for example

If they are not owned by Microsoft then start digging more using Virus Total, Alien Vault, etc to see if the ips are known command and control for any particular malware

Lots of malware will inject into and take over explorer.exe because if it's long running persistence (it stays running until the pc shuts off ). Attackers with a reverse shell using something like metasploit meterpreter will also migrate into the explorer.exe process for the same reason.

If your good at network forensics you could also sniff with wireshark and review to the capture to see if you can tell what data it's sending or if it matches any patterns or known malware families.

But otherwise the information you've provided is unfortunately too vague and matches many malware families and so it can prove to be difficult to determine what it is.

If it's illegitimate traffic and it's coming from explorer.exe it's probably time for a re-image and rebuilding that pc


How does TLS protect against a MITM cipher suite downgrade?

In short, the Finished message is a hash of the entire handshake, encrypted with the negotiated keys. The negotiated keys are derived by something protected by asymmetric cryptography. Validation of the Finished message validates the transcript of the handshake.

This is probably answered in multiple answers on SE for "How does TLS work?".


When is a group password for a closed circle of users acceptable?

It's not acceptable if you want to be compliant with regulations like Sarbanes-Oxley (SOX), which - among other things - mandates that individual users must be easily auditable.

It is fair enough (on a UNIX or Linux level) to have a group account for an application which may be assumed by an individual named user, once they have logged in (i.e. using sudo su sharedaccount), but it should not be possible to log in directly with that account. That way, it is still possible to see (via system logs) who logged in, at what time, and who assumed the privileges provided by that shared user account.


Securing a LAN without Physical Security

Does your hardware support vlans and port security?  Just run those machines on a different vlan.  Then have Access control lists to control access to the WAN.  Assuming your switches are physically secure that alone should be secure enough for most applications.  Seeing as you already have a list of mac address's to be allowed you could set up port blocking as well.

I don't usually agree with using mac addresses as a form of authentication.  It is a lot of work for something that is so easily bypassed.  It best it might deter someone from hooking up a stray laptop to the network but a half dedicated attacker could get by it in seconds.

Setting up an encrypted VPN would give an extra leyer of security if you think it is worth the extra work. A VPN is probably way less work than dealing with MAC addresses.


Why are iframes allowed at all in modern browsers?

Given that framing is deprecated, and AJAX has origin control, iframes is pretty much the only way to embed another page into yours.

Another thing is that you can use iframes to display PDFs/etc. Sure, you can use <object> for that as well, but iframes are easier.

GMail is made from iframes. The smooth UX of GMail (you can still use it when your internet connection breaks, smooth navigation without having to reload every time) comes from iframes. Again, this could be implemented in AJAX, but it's harder.

One last thing that comes to mind is backwards compatibility. A lot of sites use iframes, and disabling it would break too many of them. Sure, click-to-enable won't cut it here, either. One of the precursors of AJAX was a trick with iframes and javascript. A lot of websites used to use that, and "click to load" will break the flow of the JS.

On the other hand, issues with iframes (CSRF, clickjacking, etc) are well known to modern developers and they can take measures to avoid that.

If you look at it, the arguments in this question could be equally applied to Java applets. Or Flash. Or PDF embedding. Or images (CSRF). Or cookies. For example, other sites can CSRF you via images. It's up to you to make sure that your  site isn't vulnerable to these.


Software library for 1-2 oblivious transfer?

Normally things are done in this order:

Cryptographers come up with new ideas for algorithms and publish them.
Other cryptographers break them, then fix them again, and so on, until there is an algorithm which can be deemed "secure enough" by virtue of having survived the process relatively unscathed.
A cryptographer with a practical mind writes a specification which tells how to implement the algorithm, minding details like endianness.
A developer follows the specification and writes code.

Sometimes steps 3 and 4 are done in the reverse order: someone writes the code, and only then the specification is written to match the arbitrary conventions that the original developer decided upon (usually on a whim: e.g. you will get little-endian or big-endian encoding depending on what was simplest to do in the programming framework of that developer).

Oblivious transfer is a concept, and actual algorithms are somewhere between steps 1 and 2 right now. So no usable library: if you find an implementation, then it will be part of some research project (a cryptographer using it for research purposes, such as looking for biases and so on), but not an incarnation of a generally agreed-upon "secure" algorithm, ready for the specification step.

Theoretically, oblivious transfer being just an algorithm, it has no value by itself, but only as part of a wider protocol which uses it (and possibly other algorithms) in some way. For anything which looks like production code, you should first find (or define) that overarching protocol, which may use an oblivious transfer primitive, and from the actual protocol structure will depend the actual required characteristics of the oblivious transfer.

In a way, requesting a "library that supports oblivious transfer" is akin to sending a general request for "a combustion engine" without telling whether this is for a boat, a car, a plane or a power plant. It is a bit unanswerable.


Database Protection : External & Internal

There are situations where an external-facing database is used to store temporary information which is "pulled" not "pushed" through a one-way firewall connection into a larger internal database then that data is deleted from the external-facing one. The purpose for this is to reduce the number of records which can be stolen at any given time yet allowing data to continue to flow into the external-facing system. That said your situation may be entirely different. If the data is the same on both sides it likely isn't for this reason but one purpose for doing something like this is because can provide an additional layer of defense in depth for the databases.

Think about the case where SQL-injection attacks go through a front end server and effectively lands an attacker, sometimes with full shell-access, onto the the database connected to web app. In the case of a single database the attacker gets everything including all records. In the case I mentioned above the attacker only has access to a tiny subset of transactional records for the time they have access to the system (hopefully this is discovered and the timeline is very short). In any case, that is one reason why you might do something like this. Again your case may vary.


Are machines patched against WannaCry protected against the ongoing Petya attacks?

Making sure that SMBv1 is disabled is a good start to protecting against the Ethernalblue exploit.

The malware also uses the WMIC and PSEXEC tools to infect machines that are fully-patched Windows computers. Disabling WMIC is advised see here on how to disable WMIC: https://msdn.microsoft.com/enus/library/aa826517(v=vs.85).aspx

I have also seen people saying to block remote use of local accounts via GPO but I have not seen too much on that yet.

There are also reports saying that paying the ransom will not reward you with the decryption key as the email that is used has since been blocked.

There have also just been some reports that if you power off the machine right as the message appears than it will not encrypt the files.
https://twitter.com/hackerfantastic/status/879775570766245888

UPDATE: There seems to now be a kill switch found to stop the attack all you have to do is create a folder C:\Windows\perfc

https://twitter.com/TheHackersNews/status/879782531146461185


If I connect to a website directly (by IP) over HTTPS, can a network admin seen what IP I'm accessing?

You're still forming a direct connection to the IP address. The network admin would be able to see you're connecting to that IP even though he can't see the contents of the connection.

Using publicly available tools such as this site, in most cases they would have a decent idea about what you're trying to access.


Displaying username in profile section of a Web Application

I would say displaying the username on the page (often in the top navbar) is not a matter of security but user experience. Maybe it's possible to have multiple accounts in the application, then it's nice to see which of your accounts is currently logged in. Or maybe you have a "normal" account and an "administrative" account or such things.

In terms of security, this only may prevent you from "accidently" sign in with a different account. But that does not happen quite often ;-) Instead, a typical scneraio would be a hacker stealing your credentials or access token and uses the site with your account - but you don't stop him doing this by displaying or not displaying the username in the navbar or somewhere else.


Security design behind google's application specific password

Google's application specific passwords are random and quite long. Those passwords don't occur in any dictionary and cannot be brute forced. So, they are very strong, typically stronger than any password chosen by humans.

Using different passwords for different applications usually increases security. Since, if a password is leaked for one application it cannot be used for another appliation.


Register a new client with self-signed certificate

What does the server do in this step to validate the request?

The request includes a device specific token which has to be obtained for the registration can be finished. From the script:
if [ -z "$TOKEN" ]; then
    echo "Visit the Alohacam dashboard to obtain an activation token for this device:"
    echo "    $DASHBOARD_URL/devices/"

And how it generates the certificate (is this the self-signed certificate?)?

This is unknown. I cannot find any information in the documentation there is no source. From the README:

We're not planning a public release of our code base ...

But actually, it does not really matter. All what matters is that the certificate will be trusted by whoever accesses the device. I'm pretty sure that the certificate will not be issued by a publicly trusted CA (since no public domain names are involved). So it will either be a self-signed certificate or a certificate issued by a private CA. In both cases normal clients (like browsers) will initially not trust the certificate.

Finally, how will this be used in the future for the authentication process (asking here for the general idea, not the code)?

Again, there is no code. But based on the statement from the README a TLS connection will be initiated to the device and the generated certificate will be used to authenticate the device, i.e. the usual way of how TLS works:

We use client side SSL/TLS encryption. The Alohacam install script will auto-generate a certificate for your device. This certificate never leaves your device – we don't store it or have access to it – and you can even use your own. When a connection to your device is initiated, your browser will create a dynamic certificate (through DHE key exchange) that is valid only for that session. Both certificates use X.509 standards. We designed these security measures to ensure that only you will be able to view your Alohacam!

Actually, the last part about the browser creating a dynamic certificate through DHE key exchange does not make sense for me. I'm not sure if this is just badly worded, that they did not know what they were talking about or if I'm too stupid to understand it.


Make application use encrypted credentials from a file

There is a bit of a Chicken and Egg Problem.

The only thing that can be used is User Permission on the Device.
That means that there is a File that only the User from the Application can Read (OS-Permissions) or a Services where only the Logged In User has access to (example: Windows Credential Management API).

Any other option is just more Obfuscation than "Encryption". How will you encrypt something, where you get a secret, without enter the another secret but other users should not get your secret. All options just go to a deeper Obfuscation (first Hardcoded, secound a scrambeld String, then a scrambeld String with another Random String linked,...)


Storing passwords in access-restricted Google spreadsheets?

A threat to beware of is updates to google drive/google docs.  For example they add a feature to auto-cache frequently-used files and all of a sudden it's all on the phone in plaintext.  In fact it might already be there. Or the user installs the google drive app with default options for an unrelated reason. The big web-app firms are concerned with convenience and features, less so about security in ths sense (2FA is one thing, but once the data is in your hand it's your problem).


How long should a shared link (token in the URL) be?

That depends on how many guesses you will allow and what the chance of someone succeeding in guessing a valid encryptedDiscussionID can be. Also you need to take into account how many of such discussionIDs you will have.

If you have 1000 of these IDs and you have 10 000 possible discussion IDs it will only take on average 10 attempts to guess such an ID.

If you take alphanumeric encryptedDiscussionIDs the amount of possible IDs is equal to 26^length.

So if you take discussionIDs with a length of 10 characters you will have 1,41*10^12 possible IDs. If you have 1000 valid IDs in you database then it will take on average 1,41*10^9 attempts to guess a valid ID. I'm guessing you would be able to detect such an amount of attempts. But since adding extra characters to the encryptedDiscussionID I would make it even longer.

If you can provide more details it's possible to give a more detailed anwser.

How are you doing the server-side lookup of these encryptedDiscussionIDs. I assume you don't calculate these every time someone issues a query? Do you store them as well?

Don't forget that if someone can see (-> passive network attacker, sniffing) these encryptedDiscussionIDs on the network he will still be able to view the list of comments.


Referer value reflected in location response?

Reference (borrowed from the answer to the linked question):

https://cheatsheetseries.owasp.org/cheatsheets/Cross-site_Request_Forgery_Prevention_Cheat_Sheet.html

(emphasis mine)

Verifying origin with standard headers
This defense technique is specifically proposed in section 5.0 of Robust Defenses for Cross-Site Request Forgery. This paper proposes the first creation of the Origin header and its use as a CSRF defense mechanism.
There are two steps to this mitigation, both of which rely on examining an HTTP request header value.

Determining the origin the request is coming from (source origin). Can be done via Origin and/or referer header.

Determining the origin the request is going to (target origin).

At server side we verify if both of them match. If they do, we accept the request as legitimate (meaning it's the same origin request) and if they don't, we discard the request (meaning that the request originated from cross-domain). Reliability on these headers comes from the fact that they cannot be altered programmatically (using JavaScript in an XSS) as they fall under forbidden headers list (i.e., only browsers can set them).


How do attackers find the database technology used by a web application?

There are three common ways to deal with the variety of databases out there:

Many web applications are tied to a specific database backend, rather than being able to use a variety of backends.  For example, if someone's using MediaWiki, you know they're using either MySQL or MariaDB.
An attacker can attempt to generate an error condition, then look at the resulting error message for clues as to what database is in use.  This is one reason why error messages displayed to the end user should be as generic as possible.
An attacker can simply try everything.  There aren't that many common database backends in use, and making a dozen attack attempts isn't much harder than making one.


Welcome to Security.SE. Let's take a step back and cover some higher-level topics first which will hopefully explain what you are looking for. The short answer is this: Long-lived tokens are dangerous.

Session Management

The standard session, getting a cookie with a token that is then stored in the database or caching server like Redis, is the way browsers handled keeping a user logged in, until recently. This cookie ideally would have no meaning other than being a token to information stored in the database, filesystems, or Redis. It acted as a key for lookup.

This property allowed applications to revoke sessions (e.g. "log out of all my devices") when needed. It also gives other properties, like identifying unique devices, but it rolls up in to that revocation.

JWT

I said until recently above, because with the advent of JWT, JSON Web Tokens, JWT usually acts as a stateless token. The server has no knowledge of that token other than what the token self-describes. This is also called an assertion. There are of course mitigations to keep people from asserting things such as signing the token. Assuming that is being done here, because most frameworks default to that now, it's less of an issue than what you can do with that token.

So what now?

In the interest of transparency: I cannot stand JWT. It is fraught with issues that are probably beyond the scope of this question, and I'm not aiming to derail. I tried to avoid bias in my answer, but in case anybody reading this sees a bias, that's why. :P

To answer the question now with some of this background: Should a token be stolen off a device (browser, mobile app, etc.), there's no normal method to revoke that JWT token. Because you kept it as a forever-token, even expiry of that token would not keep unintended audiences from accessing that account data. There's no server component, except for blacklisting that token, that can protect the user and the data stored.

To sum up: JWT's only real defense is expiry of the token. There's no revocation abilities that I'm aware of to protect the account. While long-lived sessions are a bad idea in general, it minimizes user friction. Who wants to log in every single time they come here? Sites like SE can revoke sessions on the server. You'll see this ability on Google and Facebook, for example.


There are a few options that could come in handy. Our aim, I assume, is to monitor the traffic of this app:

Route phone traffic through a proxy or analyze traffic. One option for analyzing traffic is using Wireshark. Or you could manually set your phone to route through a proxy like Burp sitting on a specific IP and port.
If a lot of apps are connecting to the internet, it might be tough to zero in on just this app's traffic (not too difficult, but tedious if the not experienced with the proxy/MITM tool). In this case, use an Android emulator and debug/analyze traffic just for this app.

Using an emulator could be a quick fix if you're ok with it not dealing with real-time phone data (is it fudging with my Facebook data?), but make sure your choice of emulated ecosystem is right.


How to convince someone to use layered security?

You don't always put in every single possible mitigation you can think of.  There is a cost to this.  Security is always a compromise between risk, cost, and usability.

If you are currently in a position where you need to assess the risk of a particular threat, I suggest you take a look at OWASP's risk rating methodology .

If you follow a rigorous and objective methdology, your peers are more likely to be convinced.  And you have to be open to the possibility that the methodology yields an answer you don't like.


Checking for TLS between client and server

Use OpenSSL to attempt to connect and dump the certificate (if any).

openssl s_client -connect <server>:<port>

If it fails to connect, TLS isn't implemented. If it connects, then you'll get the certificate and you can check what it looks like.


Secure MySQL data on hosted 3rd part server

The question is where does the encryption/decryption take place. If they are run on the third party server then there are no means you can protect the key as how and where it is being stored and how it is being used depends solely on the policies of the provider.

There is some literature on the topic and there are approaches that use a key directory to store the keys which can reside either at the provider or on a trusted third party, and upon encryption/decryption keys are being exchanged by the db provider and the trusted third party by using a master key.

The granularity of the encryption can also be specified(the encryption can be done at database, table, partition or low level. A paper that highlights the workings of such a mechanism can be found here.


I'm not entirely sure I understand the question, but it appears you're looking for something like secunia, possibly for a more restricted set of software?   I believe that many of the big security firms also sell a client plug in that will detect misconfigurations; running that plug-in on your site will detect CWE/misconfigurations.

And you could always check with Tenable/nCircle; their security assessment tools can detect problems. It is a very competitive market and both of those companies devote a lot of $$ to research to ensure that they're aware of and can detect the latest CVE/CWE/etc.

NIST provides CVE and CWE information, which may also be of use.


Which properties of a X.509 certificate should be critical and which not?

In "pure X.509", it does not really matter if an extension is critical or not, because conforming implementations are supposed to honour the extensions that they recognize, be they marked critical or not. The "critical" flag is for extensions which are not standard: you make such an extension critical if it is important for security (implementations which do not understand the extension should reject the certificate), or non-critical otherwise (implementations which do not understand the extension can then safely ignore it).

There is a slight exception to this rule, with the CRL Distribution Points extension. It has two purposes: to document where CRL can be downloaded from, and to implement scope segmentation. This latter role is active only when the extension is critical. When the extension is critical, then a CRL can be deemed to cover the certificate (i.e. to be able to tell something about its revocation status) only if the CRL contains an Issuing Distribution Point extension, with a "distribution point" which matches one of those specified in the CRL Distribution Point extension in the certificate. When the extension is not critical, the extension serves only in its documentation role.

In practice, you will make extensions critical or not depending on whether they can be ignored without piercing too big a hole in the whole security, and also depending on whether making the extension critical will induce existing implementations to reject the certificate for lack of support. For instance, if you use a critical Name Constraints extension, then you risk unconditional rejection from old versions of OpenSSL (versions prior to 1.0, all of which are EOL, don't support it); but if you make it non-critical, then the same OpenSSL will ignore it. The Name Constraints extension is a typical case of an extension which cannot be ignored safely, and thus should always be marked critical (but interoperability issues make its usage potentially problematic).

RFC 5280 lists, for each certificate extension, whether a conforming CA should make the extension critical or not. These are requirements on the CA and not on validators; a system which validates a certificate must not reject it on the basis that it includes a critical Subject Key Identifier extension, even though RFC 5280 says (section 4.2.1.2):

  Conforming CAs MUST mark this extension as non-critical.

See the RFC for the details on every extension: these are guidelines for how your CA should behave. For instance, Key Usage is a "SHOULD be critical", Basic Constraints is a "MAY be critical", Name Constraints is a "MUST be critical", and so on... If you follow these rules, your security will be fine (but you may have to make some modifications for interoperability).


NMAP has a sniffer-detect script built-into it, it's probably the most simple solution out there. I have seen no comparison of the two tools on their effectiveness.

Note that all these solutions do is try and find interfaces running promiscuous mode, there are many ways to sniff a network which would leave no traces at all, for instance taps and spans.


Look, from a business standpoint, I think that if you could package it as a hosted-service, that would be a good way to avoid your code being used by unauthorised people.

There is no way to guarantee that your application isn't distributed even if you obfuscate it heavily etc to protect your I.P.

I strongly suggest selling the product with the SaaS or PaaS model where your clients use your website (a frontend) to interact with the service/product.


Trojan name I can't find any information about

The usual naming of malware is [targeted platform]/[name].[variant]

The variants of a malware are numbered alphabetically. When your AV software vendor already uses three letters to describe the variants it means that there are a lot of different variants of this particular malware in the wild.

You might find more useful information about this malware when you just search for the family PHP/Small.

However, the prefix PHP hints that it targets PHP, a server-sided web development language. When you don't have a webserver installed on your machine, it is likely a false positive.


Are there security (esp. privacy) benefits to deleting cookies?

I would say yes and no at the same time.

Advertising company are using some clever techniques (including cookies) to identify your browser :

Your classic cookies (which are now gone).
Flash cookies : you can store content in flash which can be using for cookies (very common now).
Your browser fingerprint (HTTP Header fingerprint, fonts installed, OS, browser version, Time location) with your ip address can be used to retreive information from deleted cookies.
You can store things directly with HTTP headers (HTTP cache) but I don't know a lot about it.
Css visited links (via faux links with data).
Browser cache can also be used for storing cookies

I suggest looking at the evercookie project, its quite interesting.


Security concerns in disseminating database design?

It's probably not a security issue.   For context, think about open source software.  When you have an open source application, the application source code and database schema are completely public; anybody can take a look and review them in as fine a detail as they care to. Organizations stand up and run instances of that very same open source software all the time, and no intrinsic security vulnerabilities are introduced merely by the public nature of the code/schema. It's true that vulnerabilities can be found by reviewing source, but even in this case I'm hard pressed to think of a security issue that has ever been found solely in a database schema and/or data dictionary.

So, as long as things like the table and column names, and data dictionary definitions don't intrinsically contain sensitive information or data, I don't see a security concern here.

That said, you may have an out in any case.  Your schema is probably not subject to FOIA. It looks like application source code (and similarly a database schema) is generally not considered an agency record, and so would not be eligible for release under FOIA.


Security implications of having files owned by the apache user?

Restrict the daemon with MAC

No matter how you cut it, wrapping Apache in a mandatory access control layer like AppArmor or SELinux is a good first step. That will allow you to restrict the daemon's allowable operations even if otherwise has permissions to do so. That will prevent Apache from ever modifying your files.

Use version control with automatic checkouts

If every developer has access to git and the production branch is automatically checked out by the web server when it is updated, you will have control and history of everything that is loaded as well as instant verification that everything is what it should be.

Permissions

The downside of making Apache the owner of the files is that Apache could theoretically chmod those files. For that reason, making the data directory and files within owned by another user has a benefit unless you expect Apache to alter the directory. If you do, try to separate directories for expected dynamic content and content that Apache should never update.


Justifying strong 1st factor in the context of multi factor authentication -- beyond passwords

Breaking a knowledge factor have a theorical cost we can easily assure beyond human capability (a password with 12 dicewares words will never be unhashed using unbroken 256bit hash), if we exclude human vulnerability and implementation vulnerability (and the fact nobody use a 12 words password) this is a perfect security and provable as is. (as long as we can't read human mind at least)

Bio security isn't a theorical identification it is using natural part of our identity we are now able to read but not reproduce. (your print, ADN and iris aren't prvate everyone can access them). You can't determine how secure is your authentication, you can say it need a really hard to produce device to fool your system but you still have to admit this device can be build. This is just adding technical difficulty to break your authentification process not a assurance of security.


You are correct in that there are still risks involved.
First, there are the risks that you can eliminate by following the recommendations from EFF. Only use an email client that has been properly patched. Make sure you have actually updated it to a safe version. Preferably, don't turn on rendering of HTML emails.
Then, there are risks you will have to accept if you want the convenience of decrypting emails inside your email client.  As highlighted in this answer, the people behind EFAIL discovered multiple exfiltration mechanisms, some not related to HTML. As always, there is a risk that there are more clever tricks waiting to be discovered. In fact, the cat and mouse game is already on. According to EFF, the first Enigmail fix that was published was soon circumvented. Hopefully, future fixes will have a longer half life.
That's why it's safest to just use a program separate from your email client to do the decryption. Unfortunately, while it's safe it's not a very practical option. It seems that EFF thinks the security versus usability contradiction at the core of PGP can not be solved, and that we need something better. From your link:

But if we’re to continue to use and recommend PGP for the cases where it is most appropriate—protecting the most vulnerable and targeted of Internet users—we need to carry on that conversation. We need to cooperate to radically improve the secure email experience, to learn from what we know about modern cryptography and usability, and to decide what true 21st-century secure email must look like.
It’s time to upgrade not just your PGP email client, but also the entire secure email ecosystem, so that it’s usable, universal, and stable.


Is winmail.dat a malware propagation vector?

Long answer: According to Microsoft, Winmail.dat is a file that keeps the rich-text formatting readable if sent by Outlook.  I have sniffed around a bit and found out that attachments that 'act' like the way Winmail.dat does exist.

Then again, since it's an attachment (and I hope you don't auto-open attachments from emails), you should only open it if you trust the person that send it to you, or have a good anti-virus that can scan your mail too.

Short answer: yes, attachment malware called winmail.dat exists, exploitation of a valid file is possible, because it basically contains theming.

More info on winmail.dat can be found on this website: http://support.microsoft.com/kb/278061


Prevent padding oracle attack on key exchange process

The "padding oracle" attack you are talking about is better known as Bleichenbacher's attack against RSA. The attacker sends malformed encrypted keys; some will still (by pure chance) happen to decrypt properly, albeit with a decrypted content that the attacker cannot know. If the server's behaviour changes, depending on whether the decryption failed ("bad padding") or not (server uses the decryption result and keeps going), then the attacker can obtain some information on the RSA private key.

A common workaround is to, indeed, hide the behavioural change: when the decryption fails, the server simply uses a random value instead of the decryption result. Thus, the attacker can no longer distinguish between "bad padding" and "padding was correct and resulted in some random decrypted junk". This is, in fact, rather hard to implement properly, especially since industrious attackers can apply timing attacks and notice when the server used a random replacement, because of the extra time needed to generate the replacement.

OAEP is nominally immune to Bleichenbacher's attack, and was designed precisely in that goal; however, this still requires that it is implemented correctly, which is, again, not as easy as it seems. The usual recommendation applies: if you are writing your own crypto protocol or implementation, then you are doing it wrong. You should use an existing protocol, and existing implementations where details such as resistance to timing attacks have been explored and fixed through years of on-field testing.


How trivial is identifying a Tor user with JavaScript enabled/ 'allow scrips globally'?

There are several ways to track visitors between sessions which are in no way hindered by TOR:

HTTP cookies (yes, even .onion domains can use cookies like any other domain)
Persistent storage with JavaScript in Localstorage or IndexDB
Persistent storage in plugins like Flash
Browser Fingerprinting, i.e. looking at a combination of browser version, installed plugins, screen resolution, installed fonts and what other information you can get. Each of that by itself might not be enough to identify someone uniquely but can be when you look at the combination of all of it simultaneously.

If you want to avoid getting tracked, you might want to use the TOR Browser provided by the torproject.org. It is a Firefox build with all of the above switched off as far as reasonably possible.


Being directed to hacked site only when searched through Yahoo

I have just verified this.

If the request header contains the Referer (which your browser adds after being refered by another site), you are redirected to the fake page.

This is the response, which causes the "redirect":

Now we modify the request to not contain the REFERER: header:

And the correct website is loading.

So basically, the "hacker" checks the REFERER header, and if it is set to Yahoo (or possibly others), it will show you the wrong page.


Is SSO without SSL possible and/or secure?

A quick use of a search engine points me as the first hit to stackoverflow: Are Oauth2 client apps required to have SSL connection? which cites the OAuth 2.0 specification which can be summarized with:

  ... the authorization server MUST require the use of TLS ... The redirection endpoint SHOULD require the use of TLS ...  Access token credentials MUST only be transmitted using TLS

For more information see the original answer at stackoverflow.


Can a Man In The Middle attack cause a certificate error?

Ettercap man in the middle SSL by using a certificate issued for the right common name but signed by ettercap. So you will never produce an error like ERR_CERT_DATE_INVALID by using this tool.
You will see errors like ERROR_UNKNOWN_ISSUER.

After you stop your attack, ettercap send good ARP opportunistic packets to restore the good behavior in your network. The last side effects disappear in the following 10 minutes most of the time.

So, this is not your fault.

If you want to perform ARP man in the middle without raise SSL certificate errors, you have to use the -S option.
beware, many people make the error to think that SSLstrip is about to man in the middle SSL certificates. It's wrong, SSLstrip only try to downgrade SSL connections to unencrypted ones (HTTPS to simple HTTP for example).


Client side password hashing with static salt - did I find a breach?

It depends. There is not enough information in your question to give specific answers, and probably without knowing the server side, it will be hard to evaluate.
Isn't this a breach?
I would not call it a breach just yet, because simply knowing the fact that the client hashes the password does not reveal any sensitive information about this or other accounts.
Can't an attacker sniff the passwords easily, or do a send-the-hash attack?
If an attacker can sniff the communication between the client and the server, it makes no difference, wether the original password is sent or a hash version of it. In both cases, the attacker has the credentials needed. The only thing that could stop them now would be two-factor authentication.
The best thing to do agains sniffing is enforcing HTTPS for the communication.
Is it really "salt" if it's the same for everyone?
No, a salt is some random data that is added to a one way hash function to safeguarde passwords in storage. A salt must be random and be unique for each password and should be long enough to protect agains creating rainbow tables with all possible salt combinations.
It's also not a pepper, because a pepper must be secret.
Why would you hash a password on the client side in the first place?
Hashing a password on the client side before submitting it to the server simply turns the resulting hash into the new password. While it provides no additional security during the authentication process, it protects the user's password in general (especially if they use it elsewhere as well): the clear text password is never transmitted nor processed by the server. If the server (in contrast to the database) is ever compromised, it will be more difficult to extract the original password.
PS: Hashing something with a hash function like md5 or sha is different from encrypting something. Encrypted data can be decrypted, hashed data however can not be restored as a hash is a one-way function.


Can malware be transferred from an Android device to a Desktop computer?

Your question basically boils down to, is it possible for any compromised device to infect other devices?

To which the only real answer is yes, it is possible. Unlikely perhaps, but possible.

Also, there is really no way of truly knowing if a device has been compromised, antivirus scan or not.


Alright, I've gotten some answers from asking in the IRC channel.

When you use -b, the shellcode is encoded to avoid the bytes specified. The decoder is attached to the beginning, and that code is actually readable and makes sense. This specific decoder apparently does something with XORing bytes in the shellcode, which explains why the shellcode looks like garbage when disassembled (they're not actually instructions). Also, stepping through the shellcode with GDB often will not work because GDB will replace the next instruction with 0xCC, or a breakpoint. This means the decoder will XOR the wrong bytes, causing the program to crash.

The shellcode is actually correct and I've gotten it to work for my exploit.


Does BloodHound include local users as part of the results?

Bloodhound uses active directory searches and maps only accounts it can guarantee have the same password . It cannot guarantee local non ad accounts have the same password so it does not include them .

This is a relevant issue link

https://github.com/BloodHoundAD/BloodHound/issues/227


Web Applications (http): Don't get how token based authentication is secure

Token-based authentication is not about securing the communication against third party attackers. It is to secure the server against the client himself.

For proper security you need SSL anyway. Without SSL, imagine an active attacker, e.g. that funny-looking bearded geek sitting two tables from you in the same restaurant -- you don't know it, but he has a fake WiFi access point in his backpack, and he is currently intercepting your Internet traffic, which you believe to go through the restaurant "free WiFi". That guy can hijack your communications at any point. He sees what you send to Web sites and what you receive from these sites, and he can alter both kinds of data at will. When he chuckles and almost gags on his milk-shake, that's because he is reading your emails.

To defeat active attackers, you need something which protects the data confidentiality and integrity, and makes sure that you talk to the right server, not to the Bearded-Geek-in-the-Middle. And that "something" is SSL.

With SSL, you can indeed just use HTTP Basic Authentication. This will work... provided that you want to use HTTP Basic Authentication, because that authentication is handled by the Web browser, with its own popup, which can be ugly. For instance, it may look like this:

Most Web designers are appalled at the sheer practicality and minimalism of this popup, which is reminiscent of the glorious architectural experiments from the Stalin era. Therefore, almost nobody does that. Instead, Web sites implement their own "login page", in pure HTML, and therefore cannot benefit from the inherent support of Basic Authentication by the browser. They must use a cookie, i.e. the "authentication token" which we are talking about.

Moreover, user authentication is not necessarily based on a login and a password. Some sites do funkier things, including delegating authentication to another server, using the OAuth protocol. This very site, security.stackexchange.com, does that. This again calls for some storage of data on the client browser, data which is not a login and password.

Once you begin to store data on the client browser, you may envision to store data that should remain opaque for the user himself (should he be inquisitive enough to have a look at his cookies), and which resists modifications from the user (depending on the data and what it's used for). This calls for, respectively, encryption and checked integrity. That kind of "securing" is all about storing things in the client system but without trusting the client system.


The definition of a cryptographic hash function includes resistance to preimages: given h(x), it should be infeasible to recover x. A hash function being "reversible" is the exact opposite of that property. Therefore, you can have no more a "reversible hash function" than you can have a fish allergic to water.

Possibly you might want a hash function which, for most people, is a cryptographic hash function with all its property, but which also includes some sort of trapdoor which allow reversing it if you know some specific secret. This sort of things might exist but requires mathematics, like asymmetric cryptography. I am not aware of such a construction right now, but one might possibly jury-rig something based on a RSA modulus, or maybe an elliptic curve with coordinates taken modulo a RSA modulus (I don't have a precise design in mind, but I have the intuition that it can be done that way).


Will using a self-signed SSL certificate on a mail server hinder communication?

You're fine with a self-signed certificate.

In my experience over several years, I never had any problems with a self-signed certificate on my mail server.  I eventually switched to one signed by StartSSL and there was no discernible difference in interoperability.

See also this post on ServerFault.

The bottom line is, STARTTLS is about encryption, not authentication.  While it can be locked down to perform authentication, the default of most (if not all) SMTP servers is opportunistic encryption.  SMTP is plaintext by default, and needed encryption more than it needed authentication, thus the emphasis.

It is possible to lock down connections - for example, I've seen an Ironport configured to require a valid certificate signed by a known CA it liked (in this case, it liked Entrust but not Comodo, so we ended up changing the cert because it was easier than debugging somebody else's Ironport).  But that's for locking down specific domains which want to ensure partnered encryption, I've never seen someone doing that with opportunistic encryption.


What type of encoded text is this and how can I translate it?

Since this looked like Base64 encoding, I opened the first online encoder/decoder tool from Google (https://www.base64decode.org/) and inputed your string. After decoding, got this result:

  If you found this note in a small wooden box with a heart on it, then
  congratulations! You are probably the first person to read this. I didn’t really plan on sharing this with anybody, but for some reason I
  think it’s exciting that somebody out there, a complete stranger, will
  come across this note and read my story. Someone I will never meet,
  sharing such a personal bon

As said, this is encoding, not encryption. Both of the techniques obfuscate clear text but the purpose of encoding is to protect the message from bad parsing, meanwhile the purpose of encryption is to hide it from someone who is not supposed to read it.


Yes. Even if you run a VPN on port 443, HTTPS (which uses port 443) and VPNs have enough differences within the protocols that can be distinguished from the outside that a firewall or device that does deep packet inspection would be able to immediately classify both.

If your firewall does not block a VPN connection on port 443, it is likely that the firewall is only doing port filtering, or does not have protocol signatures for VPN connections yet.


How likely is it to see a commercial IDS/IPS that uses machine learning in the near future that performs better than a normal IDS/IPS?

I think nowadays a lot of companies needs to add the words "Machine Learning" and "AI" to their products basically. But they still using the same technology as before with these new features. When a vendor shows me how cool is their solution I always ask about the detection numbers (false positives, false negatives, data sets, reaction time when a new malware is active and so on), basically I don't care of what they use behind the curtains but I care about the other metrics that are the ones that may impact me.


How exactly does Google Account decide my device or location is "familiar"?

It appears to be based on your IP address and browser cookies.

According to a Google FAQ page:

  To help make sign-in easier and more personal, you may see a screen with your profile picture and full name when signing in to Google. We’ll only show this information if you are signing in from a location or device you’ve signed in from before, like your home computer.

I tried entering my email into a VM that I've never used to log into my Google account (but has the same external IP address) and the Google account page still showed my profile picture.

I don't think it is by an IP's geographical location because multiple IP addresses may point to the same location. I've also used other networks (with different IPs) in close proximity to mine and had my device not be flagged as familiar.

I believe cookies are also used - I used to clear all cookies on browser close, resulting in my device not being marked as familiar in new locations (allowing me to make the observations above). Since I allowed cookies to persist, I noticed that my device was marked as familiar even though I logged in from a different location that I've never used before.

Summary of my observations:

Familiar devices are determined based on:

IP address (but not geographic location).
Browser cookies.


How to get rid of DNS Unlocker on Windows

There is no common guide to remove DNS Unlocker, but maybe on of the following might help:

Check the extensions 'Add-ons' and disable any suspicious one.
Clear browsing history and cached data.
Clear Host cache in Google Chrome chrome://net-internals/#dns
Check your Programs and features and remove DNS Unlocker from there.

Besides that, you need  to upgrade your Windows. Windows XP is out-dated and obsolete. Try to use more secure version of Windows OS.


Regarding Openssl.config file: What is the importance of policy matching when creating a self-signed certificate with the aid of this file?

It is an arbitrary, administrative decision for the creator of CA what client certificates they want to enable to be signed by the CA.

The policy_match in the following configuration line:

policy          = policy_match

is a chosen name that corresponds to a particular section in the configuration file. That section defines in details each of the

[ policy_match ]
countryName             = match
stateOrProvinceName     = match
localityName            = supplied
organizationName        = match
organizationalUnitName  = optional
commonName              = supplied
emailAddress            = optional

Each of the DN fields for the client certificate can be assigned to have the same value as the CA (match), be required to be specified (supplied), or be optional (optional).

The same guide suggests another policy that matches your criteria of "the client could be an arbitrary entity that has nothing in common with the CA":

[ policy_anything ]
countryName             = optional
stateOrProvinceName     = optional
localityName            = optional
organizationName        = optional
organizationalUnitName  = optional
commonName              = supplied
emailAddress            = optional

Yet if you wanted to create a CA for your organisation, that would allow issuing only certificates for that part of your organisation you can freely set for example:

policy          = policy_branch_1

[ policy_branch_1 ]
countryName             = match
stateOrProvinceName     = match
localityName            = match
organizationName        = optional
organizationalUnitName  = optional
commonName              = supplied
emailAddress            = supplied

Which would required the issued certificates to have first three DN fields matching the CA's certificate.


Is this ASP site vulnerable to XSS or not?

The encoding that is happening is URL encoding ("<" is encoded to "%3C" and so on). This is done by the browser when you type special characters in the URL.

This can be verified by intercepting the request going from the browser to the server using a proxy like Burp Suite.

Now, if you add your script in Burp instead of the browser, the script will certainly reflect back in the response without encoding. The same can be achieved by manually crafting a HTML page to fire the request.

The actual mitigation you are looking at is proper HTML encoding (&lt; and &gt; for "<" and ">"). In order to completely make your application armoured and protected against XSS, I would recommend using the ASP.NET's ValidateRequest filter along with a custom application-wide filter which encodes special characters in all requests.

The application should not accept any script, special character or HTML in fields whenever not required. It should escape special characters that may prove to be harmful. The characters can be escaped as per the list available at this link:

TheUKWebDesignCompany.com, HTML Escape Characters: Complete List


What can be disadvantages (impacts) of keeping passwords in plain text in web browser?

The attacker can't abuse this flaw any more than what he can do already without the flaw.

You probably have an impression that websites (and web browsers) which don't allow you to see the actual password in the HTML are protected against an attacker who would get ahold of your computer during filling in the login form. This is not true since:

I can use web inspector tool to sometimes extract the password directly (as you can in your case)
I can use the javascript console to extract the password with DOM access methods
I can use the network monitor in the web inspector tool, submit the form and analyze the request parameters to extract your password

So it can hardly be considered a flaw.


Server takes 30 seconds to respond to simple request. DoS?

What are the chances that this could be used for a DoS attack and how
  serious would that be?

The chances are good. If a specially crafted request causes an unusually long waiting time that's a good indicator that you're occupying a thread on the server and found a potential Denial of Service attack vector. DoS bugs often get overlooked in web applications but there are quite a few ways in which they can occur (SQL wildcard attacks, pending network requests, etc.). Against many web frameworks there have been published advisories on DoS flaws, like this one for Wordpress.

The severity obviously depends on the service they're running. A small web shop could lose a few potential customers - on the other hand, for a bitcoin trading site it could result in great money loss.

  I'm asking because I'm hesitating to submit this bug to the app owner
  who is running a bug bounty program as I do want to avoid negative
  feedback/reputation.

Bug Bounty Programs often explicitly exclude DoS vulnerabilities from their scope. But that doesn't mean they're not interested - rather, vendors are often afraid to encourage attacks which would likely impact their services (which a DoS clearly does).

I would still report it. BBPs have rewarded DoS flaws in the past, for example here or here. I'd clarify that you have not actively been looking for DoS bugs but found behavior that strongly indicates that a DoS attack vector might be there. I'm sure they're interested to have a look at this if they recognize you as a responsible researcher.

There is also this OWASP guide on testing for DoS vulnerabilities, but as said, I wouldn't actively do it without permission. That wouldn't be the first time someone got banned from a BBP.


Could revealing your full name on the internet be dangerous?

Yes and no. What matters about online security isn't about keeping all personal information about yourself totally tight lipped, but being able to control the amount of personal information you disclose in the right context.

Online security is about being in control of how you present yourself and your online identities, and how to prevent others from being able to link the personas that you want to keep separate.

For example, on sites where you discuss your professional interests and such, you may want to use your real name, to build your personal brand that you can use with employers. On social networking sites where you associate with friends and hope to be searchable by old, lost friends, you may want to use the name you expect those people would be able to search, which is likely going to be your real name. On sites where you discuss your guilty pleasures or where you discuss sensitive political issues from viewpoints that may get you in trouble with friends and families, you may want to use a different identity which can't be tracked back to your real identity and which you should never tell anyone in your real life about. In sites where you discuss things that can get you into trouble with authorities, you may want to decide to use a throwaway identity. On sites where you do online activism, where you do need a persistent identity so people can contact you, you may want to create an anonymous identity.

Depending on how much protection you want and the sensitivity of each personas, partitioning may include using a separate email, and in some circumstances, a separate browser profile or virtual machine, and only used via proxy/tor. You may want to have multiple such identities/personas, depending on how much you want to partition your online identities and how problematic it would be for you if anyone linked those personas together.

To keep your online identities personas from being linked, you would want to learn the techniques that can be used to link up your identities. These are techniques such as Cookies, Supercookies, browser and OS fingerprinting, IP address, drag net surveillance, spyware, etc. Some of them may not be relevant to you, but you would want to learn their capabilities and how to avoid that particular techniques when they're relevant.

Or, you may decide that you want to live your life the same online and offline unashamedly, and just deal with the repercussions with a hard head. That's a valid choice as well, but be sure that when that happen that's your choice and you are in control, rather than a situation where you find yourself helplessly into.


There is very little point in encrypting this password - as you suggest, the encryption algorithm and key and salt will all be available to any attacker in any event. All encrypting will do is slow them down slightly at the expense of complexity and difficulty in rotating the password/key for the external system.

The appropriate mechanisms here are either file system permissions preventing non-authorized people from reading the configuration file (the traditional method) or a key storage mechanism such as a Hardware Storage Module (expensive! possibly overkill), a software equivalent (KeyWhiz, Hashicorp's Vault are examples) or available services (if in AWS, for instance, AWS Key Management System).


Can university vpn see the websites i visit?

It depends on whether or not the connection to the VPN is a split tunnel connection.
If it's a split tunnel connection, then only connections to hosts that are on the same internal network as the VPN end point are routed through the VPN.  All of your other connections (e.g. to public websites such as Google, StackExchange, etc.) are not routed through the VPN.  In this case, the operator of the VPN (your university in this case) would only be able to see the hosts that you are connecting to which are on the same internal network as the VPN, and would not be able to see the hosts that you are connecting to which are not on the same internal network as the VPN.
If it's not a split tunnel connection, then all of your connections are routed through the VPN.  Therefore, the operator of the VPN  would be able to see all of the hosts you are connecting to while you are using the VPN.
A simple way to test whether or not it's split tunnel connection is to do the following:  1)  With the VPN deactivated, point your web browser to www.whatismyip.com, and note the address that the site sees you connecting from.  2)  Activate the VPN, then point your browser again to www.whatismyip.com, and note the IP address that the site sees you connecting from.  If the IP address is the same in both cases, then it's not a split tunnel connection.  If the IP address in (2) above is not the same as the IP address in (1) above (i.e. the IP address in (2) above is an IP address assigned to you by the VPN), then it's a split tunnel connection.
Notwithstanding all of the above - if your connection is routed through the VPN, and you connect to a site using HTTPS then (barring a MITM   or similar type of attack), the operator of the VPN would be able to see which sites your are connecting to, but would not be able to see the information transferred back and forth between you and the sites that you visit.


What is the most secure way to access clients' VPNs?

Software Vendors with privileged network access are increasingly used by hackers to gain access to sensitive networks. A good example of how a of how a software vendor with VPN access can lead to a massive data-breach is the 2013 Target hack.

The point of a VPN is to segregate access. A Virtual Machine can also be used to segregates access, however if the host machine is compromised, then all of the tenant VMs are also boned. Simply saying that you use a VM doesn't automatically give you a separation of trust - this is just security theater.

Consider the following measures to improve  security posture:

Use a dedicated machine for accessing this senstive network.
Have a trained professional conduct regular internal-network security assessments of the protected
network and all adjacent networks.
Ensure trusted machines are regularly updated, and have endpoint
security measures in place.


Determining whether a local area network is encrypting information in transit

There are lots of protocols on a LAN that use encryption, so if you know you are using one of those, you can make some assumptions.

But you open up the question when you say "all outgoing traffic" because it is possible that proxies force unencrypted traffic on the LAN but turns it into encrypted traffic outside the LAN, even though you specify that you wanted to use encryption (like HTTPS).

WiFi communication can be encrypted, too, but only on one layer of the communication. So, it is possible to say that "all your WiFi communication is encrypted" but as soon as it hits the switch, anyone on the LAN can read it in plaintext. But it depends on the layer of the communication that you are asking about.

The shortest route to an answer is to ask the network technicians about what encryptions are used and where, but they might not give you a complete answer for your specific situation.

The only way to be sure is to see the traffic itself by using a packet sniffer. It's the reason they exist. Wireshark, for instance, is small, easy to use, and has tons of pre-packaged analyzers to help you answer these types of questions.


Things to remember while building a password manager

I agree with Mike Scott's comment that it's best to use something which is already open-source which has gone through all the research and so on. If your doing the project for learning and personal usage then start off with basics such as:

If you support clipboard don't forget to clear it during application been closed or after a set time period.
Don't leave text in memory after it's usage
Do good amount of research into encryption for your database and enforce a good password policy
Support keyfiles for higher level of security
Don't store any confidential information as plain text on disk
Don't support any network related APIs or if you do make sure you validate all your buffers to avoid any remote buffer overflows.

You could go alot more into malware targeting your software using APIs such as FindWindow to read the strings out of your application and code injection using CreateRemoteThread but I'm not too sure of how complexity you want to secure the password from been stolen via malware.

I'd recommend you look into the code of an reputable password manager which is open-source as they will of done the above and more.

I know this list doesn't cover everything but I hope it's a good starting point for you.