DeutschEnglish

Submenu

 - - - By CrazyStat - - -

20. September 2017

How to find out the real name belonging to an email address for 1 cent through paypal

Filed under: Security,Uncategorized — Christopher Kramer @ 18:36

Paypal allows you to transfer money to your friends and family. To do so, you just need the email or phone number of the recipient. I just did this and noticed something interesting: I just gave the email address of the recipient, but in the list of transactions, paypal shows the full real name of my friend as recipient, and also sent me a mail that contains the full name. This means, you can easily find out the real name assigned to some mail address that is used as a paypal account by just sending a cent to the address. Of course the recipient will notice it, but probably will not complain.

This is especially interesting as paypal itself says in the footer of every email that scam mails will usually not include your real name. But scammers could first send you a cent to find out your real name and then greet you with your real name in the scam mail.

It seems to be a good idea to use an email address for paypal that you use nowhere else. This way, it is not possible to find out your real name through your normal mail address. Additionally, this has the advantage that you can ignore any phishing mail that you receive in the name of paypal, but through your normal mail address and not your paypal mail address.

Recommendation

Try my Open Source PHP visitor analytics script CrazyStat.

16. March 2016

Typo3: Redirect backend to https and frontend to http

Filed under: PHP,Security,Server Administration,Typo3 — Tags: , , , , , , , , , — Christopher Kramer @ 20:02

If you are using SNI to secure the access to your site through SSL, you might decide that you do not want to use SSL for the frontend, as users of old clients such as Android 2 or Internet Explorer 8 on Windows XP won’t be able to access the site. But for the backend, old clients should not be a problem.

So this solves the redirection in two ways:

  1. Frontend gets redirected to HTTP if accessed through https (optional)
  2. Backend gets redirected to HTTPS if accessed through http

Put this in your .htaccess after “RewriteEngine On” (assuming Apache webserver):

# 1. optionally: redirect FE to http
RewriteCond %{HTTPS} on
RewriteCond %{REQUEST_URI} !^/?typo3
RewriteRule (.*) http://%{HTTP_HOST}%{REQUEST_URI} [R=301,L]

# 2. redirect BE to https
RewriteCond %{HTTPS} off
RewriteCond %{REQUEST_URI} ^/?typo3
RewriteRule (.*) https://%{HTTP_HOST}%{REQUEST_URI} [R=301,L]

And hopefully, your backend access is now securely encrypted…

https

 

5. June 2015

Zimbra: Redirect http to https

Filed under: Linux,Security,Server Administration — Tags: , , , , — Christopher Kramer @ 11:15

Zimbra without Proxy (pre 8.5)

That’s the easy way how you can enforce https encrpytion by redirecting http to https:

su – zimbra
zmtlsctl redirect
zmcontrol stop
zmcontrol start

Works at least on Zimbra 8.0 and I think should also work on 7

Zimbra with Proxy (required from 8.5+)

With Zimbra 8.5+, a Proxy is required. This makes the configuration a little different. To configure the proxy to redirect http to https, run:

su zimbra
~/libexec/zmproxyconfig -e -w -o -a 8080:80:8443:443 -x both  -H `zmhostname`
# if your proxy is local:
zmprov ms `zmhostname` zimbraReverseProxyMailMode redirect
# if your proxy is proxy.server.name
zmprov ms proxy.server.name zimbraReverseProxyMailMode redirect
zmcontrol restart

With the latest Zimbra versions, the restart is not even necessary, it automatically detects the change within 2 minutes.

Hope this helps somebody!

1. September 2013

MySQL: reset a forgotten MySQL root password

Filed under: DBMS,Linux,Security,Server Administration — Christopher Kramer @ 14:37

Just in case you don’t know the password of your MySQL root user anylonger, this is how you can set a new one.

Windows users, follow this guide.

Linux / Unix users: This is for Debian (wheezy) and MySQL 5.5, but should work more or less the same on any linux/unix:

  1. Stop the MySQL server
    service mysql stop
  2. Create a init file:
    touch /etc/mysql/mysql-init
  3. Write the following into this file (adjust the PW):
    SET PASSWORD FOR 'root'@'localhost' = PASSWORD('MyNewPassword');
  4. Restart MySQL with this init-file:
    mysqld_safe --init-file=/etc/mysql/mysql-init
  5. The new password should work now. Try it:
    mysql -u root -p
  6. Restart MySQL normally:
    service mysql restart
  7. Remove the init-file
    rm /etc/mysql/mysql-init

And you’re done. I hope this helps somebody.

Note: if it does not work, it is most likely because the MySQL process cannot access the init-file (e.g. because of missing access rights). In this case check your (sys)logs for stuff like this:

mysqld: 130901 14:20:30 [ERROR] /usr/sbin/mysqld: File '/root/mysql-init' not found (Errcode: 13)

I had this problem first because I tried creating the init-file in /root where the mysql-process was not able to read it.

5. May 2013

Online-Banking: Sicherheitslücke Auftragsvorlage

Filed under: Security — Tags: , , , , — Christopher Kramer @ 15:29

Auftragsvorlagen sind eine praktische Sache: Überweist man häufiger an den gleichen Empfänger, spart man es sich, jedes mal die Bankverbindung des Empfängers heraus zu suchen. Doch die Umsetzung von Auftragsvorlagen im Online-Banking vieler Banken öffnet ein Angriffsszenario, welches es ermöglicht, das TAN-Verfahren zu umgehen. Und das unabhängig davon, ob (i)TAN-Listen, Chip-TAN oder mTAN zum Einsatz kommt.

Angriffsszenario

Angenommen ein Angreifer gelangt, z.B. durch einen Keylogger oder Phising, zu den Zugangsdaten zum Online-Banking (Nutzername + PIN). Nun kann er sich im Online-Banking einloggen und bestehende Auftragsvorlagen ändern. Dazu verlangt keine von mir getestete Bank eine TAN. Er kann beispielsweise Kontonummer und BLZ durch seine eigene Bankverbindung ersetzen. Ändert er auch den Namen des Kontoinhabers, so wird dies dem Opfer in der Regel auffallen.  Da die Banken den Kontoinhaber aber nicht überprüfen müssen, kommt das Geld auch an, wenn der Name nicht angepasst wird.
Vorzugsweise wählt der Angreifer eine Auftragsvorlage, die das Opfer häufig oder mit großen Beträgen nutzt. Welche das sind, kann er ja in der Kontoübersicht leicht einsehen.

Loggt sich das Opfer nun ins Online-Banking ein und nutzt die manipulierte Auftragsvorlage, wird es in der Regel Kontonummer und BLZ nicht überprüfen, da es nicht davon ausgeht, dass sich diese ohne eigenes Zutun verändert haben (hätte man Kontonummner und BLZ des Empfängers im Kopf, müsste man keine Auftragsvorlage anlegen). Somit autorisiert das Opfer eine Zahlung an den Angreifer durch eine TAN, ohne dies zu beabsichtigen. Bei einigen TAN-Verfahren wie chipTAN oder mTAN werden dem Opfer noch einmal die manipulierte Kontonummer angezeigt, da das Opfer diese aber i.d.R. nicht auswendig kennt und auf die Auftragsvorlage vertraut, wird es die Zahlung trotzdem bestätigen.

Gelangt das Geld auf das unter fremden Namen eröffnete Konto, kann es der Angreifer sich von diesem Konto z.B. bar auszahlen lassen.

Zusammengefasst stellt das Angriffszenario für Angreifer eine Möglichkeit dar, das TAN-Verfahren zu umgehen. Da es voraussetzt, dass es dem Angreifer gelingt, PIN und Nutzernamen des Opfers (ohne dessen Wissen) zu stehlen schätze ich das Risiko nicht all zu hoch ein.

Dennoch bedeutet es, dass ein einfacher (unbemerkter) Phishing-Angriff auf Nutzername und PIN ausreicht, um Geld zu erbeuten. Es ist nicht nötig, an TANs des Opfers zu kommen.

Lösung

Die Lösung des Problems liegt auf der Hand: Beim Anlegen, Ändern (und evtl. Löschen) einer Auftragsvorlage sollte auf jeden Fall eine TAN abgefragt werden. Wird die Vorlage im Zuge einer Überweisung erstellt, die ohnehin per TAN bestätigt wird, ist es nicht nötig eine zweite TAN abzufragen. Ich hoffe, dass den Banken mit der Veröffentlichung dieses Angriffsszenarios das Problem bewusst wird und sie ihr Online-Banking entsprechend anpassen.
So lange dies nicht geschehen ist, bleibt dem Nutzer nur, Auftragsvorlagen bei Anwendung zu überprüfen oder gar nicht erst zu verwenden. Natürlich gilt, dass man nicht leichtfertig mit seiner PIN umgehen sollte, also nicht auf Phishing-Mails reagieren, seinen Rechner frei von Schadsoftware halten und Online-Banking nicht an öffentlichen bzw. fremden Computern zu verwenden, da auf diesen Keylogger installiert sein könnten.

Update: Wie ich jetzt gelesen habe, müssen Banken den Kontoinhaber gar nicht überprüfen. Es ist also nicht nötig, ein Konto unter falschem Namen anzulegen, man sucht sich einfach eine Bank aus, welche den Kontoinhaber nicht prüft, was wohl die meisten Banken so handhaben werden. Ich habe den Artikel entsprechend angepasst.

26. January 2013

Funny pseudo-exploit for phpLiteAdmin

It seems people really got interested in the security of phpLiteAdmin. That’s cool, lots of people searching for security issues will give us the opportunity to fix a lot of things in a short period of time. Go on searching. We’ll go on fixing.

But some of these exploiters only publish an “exploit” that contains no real issue at all. Probably only to get some publicity, or maybe because they don’t even realize that what they “found” is not an issue at all. Or meant as a joke?

I recently found a new “security exploit” listing several “vulnerabilities”, which in fact are no bugs of phpLiteAdmin at all but misconfiguration or even features. So here I want to have a look at an “exploit” released by “KedAns-Dz”:

1-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=0
0     _                   __           __       __                     1
1   /' \            __  /'__`\        /\ \__  /'__`\                   0
0  /\_, \    ___   /\_\/\_\ \ \    ___\ \ ,_\/\ \/\ \  _ ___           1
1  \/_/\ \ /' _ `\ \/\ \/_/_\_<_  /'___\ \ \/\ \ \ \ \/\`'__\          0
0     \ \ \/\ \/\ \ \ \ \/\ \ \ \/\ \__/\ \ \_\ \ \_\ \ \ \/           1
1      \ \_\ \_\ \_\_\ \ \ \____/\ \____\\ \__\\ \____/\ \_\           0
0       \/_/\/_/\/_/\ \_\ \/___/  \/____/ \/__/ \/___/  \/_/           1
1                  \ \____/ >> Exploit database separated by exploit   0
0                   \/___/          type (local, remote, DoS, etc.)    1
1                                                                      1
0  [+] Site            : 1337day.com                                   0
1  [+] Support e-mail  : submit[at]1337day.com                         1
0                                                                      0
1               #########################################              1
0               I'm KedAns-Dz member from Inj3ct0r Team                1
1               #########################################              0
0-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-==-=-=-1
Okay yeah. We know exploiters love ASCII art. Kind of cool, agreed.
###
# Title : phpLiteAdmin v1.8.x->1.9.x (SQLi/FD) <= Multiple Vulnerabilities
# Author : KedAns-Dz
# E-mail : ked-h (@hotmail.com / @1337day.com)
# Home : Hassi.Messaoud (30500) - Algeria -(00213555248701)
# Web Site : www.1337day.com .net .org
# FaCeb0ok : http://fb.me/Inj3ct0rK3d
# TwiTter : @kedans
# Friendly Sites : www.r00tw0rm.com * www.exploit-id.com
# Type : proof of concept - webapp 0day - remote - php
# Tested on : Windows7
###
# <3 <3 Greetings t0 Palestine <3 <3
# F-ck HaCking, Lov3 Explo8ting !
As I said. I like exploits as well. Even if they just make me laugh 😉
######## [ Proof / Exploit ] ################|=>
# Google Dork :
# allintext:"Powered by phpLiteAdmin | "
##################
# [!] Description:
------------------
phpLiteAdmin is suffer from multiple vulnerabilities / bugs in
v1.8.x to-> 1.9.x , the attacker can use some bug in the Script
to inject some remote SQL command/code , and Disclosure the Full Path.
Interesting to say 1.9.x when there are still 1.9.x versions to be released in the future. So you are sure we won’t fix your “bugs”? Probably you are right 😉
# Bugs :
#-------
# Authentication Bypass
# SQL Injection/Exec
# Full Path Disclosure
#######################
#### (1) Authentication Bypass :
--------------------------------
[!] php-code :
line 38->39 :::::::::::::::::
//password to gain access
$password = "admin";
:::::::::::::::::::::::::::::
- not affected on all targets, just change the password to fix it
LOL
[+] http://[target]/[path]/phpliteadmin.php
[*] password : admin
I didn’t know we call it an “Authentication Bypass” if we use the authentication system by entering the correct password. Yeah, phpLiteAdmin has a default password, which is “admin”. No secret here. I mean, anybody keeping the default password on a publicly accessible installation should know that other people could get access. Current version of phpLiteAdmin even shows you a warning if you still use the default pw.
No “bug” or “vulnerability” at all.
#### (2) Full Path Disclosure :
-------------------------------
[+] http://[target]/[path]/phpliteadmin.php?view=import
[!] & Import File with (NULL/Bad) Content =>
- you get some sql error msg with the full path of phpliteadmin.php
ex: '-------------
Warning: PDO::exec(): SQLSTATE[HY000]: General error:
trying to execute an empty query in C:\Program Files\EasyPHP-12.1\www\phpliteadmin.php on line 987
____________________________________
Warning: SQLiteDatabase::queryExec() [sqlitedatabase.queryexec]: Cannot execute empty query.
in /homepages/20/d421371141/htdocs/pauleschoen.com/cgi-bin/phpliteadmin.php on line 646
------------------'
proof image (http://i46.tinypic.com/ddmek5.png) # in local test
proof image (http://i49.tinypic.com/juepet.png) # in remote test
LOL. That’s one of the most difficult ways to make phpLiteAdmin produce a PHP error message 😉
Probably you should configure your webserver correctly. Everybody who enables php-ini directive “display_errors” on a public server effectively provokes a “full path disclosure” somewhere. Maybe you should better publish an exploit for php itself 😉
Okay, seriously: We could use ini_set to make sure phpLiteAdmin won’t show any php errors. We probably will. But nevertheless, on about any php-server, you’ll find another script where you can provoke a php-error.
I am not saying it is good that these errors can happen at all. Of course it’d be better to improve checking of input and catch errors properly. This would be a real issue. But not a “vulnerability”. If these errors get displayed, your webserver is configured in a vulnerable way, which is not the fault of phpLiteAdmin.
#### (3) SQL Injection :
------------------------
php-code ::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::
$query = "SELECT * FROM ".$db->quote_id($_GET['table'])." WHERE ROWID = ".$pks[$j];
:::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::
[+] http://[target]/[path]/phpliteadmin.php?action=row_view&table='
[&] http://[target]/[path]/phpliteadmin.php?action=row_view&table=' [ SQLi ]
If you publish an SQL injection exploit, why don’t you insert some real SQL as a proof of concept? Maybe because what you “found” here in fact is no SQL injection at all?
The function quote_id() will make sure you cannot inject some other SQL command. Of course you can “inject” some invalid table-name, which will make phpLiteAdmin show up some errors, as your “proof image” shows. So another complicated way of producing an error message. Congratulations! But you cannot inject a “DROP Table” here or something like that.
Moreover, it is ridiculous to even search for an SQL injection in phpLiteAdmin. If you are logged into phpLiteAdmin, you can of course perform any SQL command. That is what phpLiteAdmin is made for. It even gives you a GUI to perform SQL queries in a comfortable way. No need to inject them via parameters.
As long as you cannot inject an SQL query without authenticating properly, any “SQL injection” in phpLiteAdmin is not a security vulnerability but a normal issue. If some table has a special name, e.g. containing quotes, we need to make sure the name is escaped properly so phpLiteAdmin works as expected. But this is not the case here: quote_id() will make sure every table-name will be escaped properly. No issue here at all.
#### (4) Exec SQL code :
------------------------
Go to :
[*] http://[target]/[path]/phpliteadmin.php?view=sql
-& put the SQL Code in the text-area (Run SQL query/queries :)
and click 'GO' to exec ;) .
LOL. That’s a really funny one. You might call this a vulnerability, I’d call it a feature.
Don’t you show yourself here that issue 3 is ridiculous?
So I am not sure if this exploit really was meant seriously or if it was meant as a joke. It made me laugh anyway.
I hope you enjoyed it as well. Keep on exploiting!

 

15. January 2013

phpLiteAdmin 1.9.3.3 released fixing an XSS vulnerability

Filed under: PHP,phpLiteAdmin,Security — Tags: , , , , , , — Christopher Kramer @ 11:53

It seems currently people have a very close look at security of phpLiteAdmin. This is really good. We immediately fix any security issue we get aware of. Therefore, we yesterday released another security patch with version 1.9.3.3. The security issue fixed in this version is an XSS vulnerability. The risk of this particular issue is considered medium. All users of phpLiteAdmin < 1.9.3.3 are advised to update to the new version. Users of the development version of 1.9.4 should please update to the latest revision from svn, at least revision 317 (2013-01-14).

We are really sorry for those users who needed to update phpLiteAdmin three times in the last days. But the only way to solve security issues is to patch, just ignoring them will not help.

Thanks a lot to Urd for making us aware of this issue. If anybody thinks he found a security issue, please do as Urd did and contact us.

To update phpLiteAdmin, just download the new version, adjust the configuration and replace the phpliteadmin.php with the new one.

Christopher Kramer,

member of the phpLiteAdmin team

12. January 2013

phpLiteAdmin: Another security release 1.9.3.2

Filed under: PHP,phpLiteAdmin,Security — Tags: , , , , , , — Christopher Kramer @ 01:27

Yesterdays security release for phpLiteAdmin unfortunately did not fix the security issues described by an exploit published by “l@usch” completely. Therefore, today a new release 1.9.3.2 was published to cover the remaining issues.

All users of phpLiteAdmin < 1.9.3.2 are advised to update their installation to 1.9.3.2. The fixed security issues can only be used by users with access to phpLiteAdmin, i.e. users that know the password. As a general recommendation, you should always use a secure password an keep it secret. Never use the default password on a publicly accessible installation.

I’d like to thank l@usch for reporting the issue and his cooperation to resolve it.

To update, just download the new version, adjust the configuration and replace your old phpliteadmin.php with the new one.

11. January 2013

phpLiteAdmin: Release 1.9.3.1 fixes a security issue

Filed under: PHP,phpLiteAdmin,Security — Tags: , , , , , — Christopher Kramer @ 00:07

Today, a security issue of phpLiteAdmin was discovered and published. The new version 1.9.3.1, which has just been released, fixes this issue. All users of phpLiteAdmin are recommended to update their installation to the current version 1.9.3.1.
The security issue can only be used by users with access to phpLiteAdmin, i.e. users that know the password, to gain more rights on the system. Therefore, the issue cannot be exploited if you use a strong password an keep it secret. For this reason, this is always recommended. Please never use the default password if phpLiteAdmin is publicly accessible over the internet.

To update phpLiteAdmin, just adjust the configuration in the new version and replace the phpliteadmin.php with the new one. Done in a minute or two.

You can download the new version here.

3. November 2012

phpLiteAdmin 1.9.3 released (security-update)

Filed under: DBMS,PHP,phpLiteAdmin,Security,Server Administration — Tags: , , , , , , , , , , — Christopher Kramer @ 00:45
Screenshot of phpLiteAdmin 1.9.3

Screenshot of phpLiteAdmin 1.9.3

Some minutes ago, I released the new version of phpLiteAdmin, a web management GUI for SQLite databases written in PHP. You can download it from our project site.

The new version addresses and mostly fixes lots of issues. Among these, one security issue has been fixed. Therefore, I’d recommend anybody using phpLiteAdmin to update.

A lot of work has gone into this release, fixing lots of bugs to make phpLiteAdmin more robust. For example, you can now have tables or columns containing special characters. The ALTER TABLE features have been partly rewritten so they now work a lot more reliable. And lots of other issues have been fixed. Thanks to anybody who reported bugs to the bug tracker.

If you still have any problems or suggestions, please let us know on our issue tracker.

Older Posts »